ステージとスキル
This page refers to Portfolio classic plans. If you are currently running Portfolio 2.0, please check this link to access the latest page version.
ステージ
Stages represent different activities required to deliver a work item. Typically, stages are used for activities that need to be done sequentially per work item.
A typical example for stages in a Scrum team that is using hours/day estimation could be:
- Story writing (responsible: Product Owner)
- Implementation (done by the cross-functional Scrum team)
Intuitively, this means that a story needs to be written, before the implementation of it can be done.
Another likely setup could be:
- Design
- 実装
- テスト
In this configuration, the testing effort is planned separately after the implementation of an individual story is completed.
Skills
Skills can be defined per stage and allow to categorize different types of work within a stage.
Example: within a design stage, one activity could be UI design, another one could be technical/architecture design. In an implementation stage, skills could be used to distinguish different technology expertise like web/frontend development, data management, etc.
Tip: Use skills for those cases where they potentially cause bottlenecks in planning, i.e., if you have specializations among your team members and need to make sure that the capacity plan is realistic in terms of who is planned for which work items.
Sample scenarios
In the following sections you'll see different scenarios examples:
In this first example, we'll take a fully cross-functional Scrum team. This means, aside of writing user stories, everyone in the team can do every type of work needed to implement a user story.
The setup will look something like this: in a first stage, the product owner writes the user story, in a second stage, the team will implement it. All activities such as UI/visual design, coding, testing, delivery etc. are done within the same iteration.
The configuration of stages will be very simple in this case, just adding two stages, without any skills.
Everyone (except for the PO in this case) can take over any implementation task, so everyone just has the Implementation skill, as depicted below:
As a result, the schedule will look like this when adding some stories: the story writing stage (light blue) will be scheduled at least one sprint before the implementation (blue), except for stories, that don't require story writing effort (such as "Technical Prototyping" in the example below).
If you do not want to estimate and reflect story writing effort at all in your capacity plan, but rather plan it separately, it is easy to just leave out a stage completely. Let's assume this scenario:
All that is needed in this case is the implementation stage. Also, the Product Owner does not need to be modeled in the capacity plan at all.
The schedule is now based on the assumption, that all required input (user stories, requirements,..) will be available for the team as soon as the stories are scheduled.
Caution, v gives you flexibility in configuring and using it the way it best matches your process.
However, we recommend to represent all types of effort (stages/skills) in your plan rather than planning some activities separately. Particularly, being realistic and explicit about design work and user story writing, or also requirements analysis is one of the common challenges many teams see in their organization.
In the second scenario, we'll assume there are some specializations in the team. I.e., everyone can take over some tasks such as testing, but there's only two people taking care of design, and also for implementation, there's some specializations:
In order to model this scenario, simply add the specializations as skills for the corresponding stage (in this case: implementation).
Additionally, define assign the skills for each of the team members:
In this scenario, the team works on a day-to-day schedule, rather than doing iterations. The work is structured into design, implementation and test, happening sequentially per work item. However, rather than waiting for the next iteration to start with the next stage of work, in this case implementation can start on the next day after design has been completed.
Here's how this team setup could be modeled:
- Switch the team schedule to Kanban mode
- Define 3 stages: Design, Implementation and Test
- Add specializations for stages where needed (e.g. frontend, backend and data management) in this example
The schedule will look different for Kanban teams: the stages are scheduled sequentially per item. If there are free capacities, multiple stories can also be scheduled in parallel. The focus is on completing stories end-to-end from design through testing in the shortest possible time period.
Stages and skills with story points
Scrum methodology doesn't recognize the idea of Stages and Skills. However, if you work with story points and would like to use stages and skills for fine grained capacity planning, this is fully supported by Portfolio for JIRA. The only assumption that needs to be made is that every team member contributes equally to the team's velocity. See Settings estimates with story points for more information.