Advanced Roadmaps

[Rashmi Ratnani]

Hello!

Referring to this article here. 

How your plan assigns capacity | Jira Cloud | Atlassian Support

What should we add as sprint velocity when we are newly using roadmaps for sprint planning?

I would like to see the capacity distribution per team member.

I see that the value is editable here in plans but where does this number get populated from?

Thanks. 

[Dick]

Hi @Rashmi Ratnani 

In the retrospective, agile teams iteratively learn to estimate story points by comparing the complexity and size of stories to stories of similar work that were done in earlier sprints. This process is different for each team. There is no "story point normalization" between teams. So 100 story points worth of work in one team doesn't have to be the same for another team.

As a result, the velocity (expressed as story points per unit of time) of a team is something that consolidates somewhat over time, and is team-specific. The story points for teams in the Roadmaps are therefore prone to change over time (you need to update these yourself).

Roadmaps allows to work out scenario's by adding a (virtual) team or expanding existing teams by increasing their velocity (through hire of extra team members and assuming their onboarding only marginally impacts overall team velocity). 

What this does, it allows for predictions on how much extra manpower is needed to speed-up a certain task or tasks that are part of the critical path needed to achieve a certain high-over goal. These scenario's can be used to support high-over executive decision making. 

Kind regards,

Dick

[Rashmi Ratnani]

Thank you for the explanation, @Dick

What would you recommend a "beginner" team to add as velocity when experimenting with this?

[Dick]

Let the beginner team start with chunks of work that they deem "are the same amount of work and complexity". That would give them the feeling of let's say 8 story points each (arbitrarily). 

See if the sprint goal is reached, and use the retrospective to evaluate the total amount of story points finished during that sprint. Determine together what number of story points would be feasible in the next sprint, based upon the assumption that similar work would be needed to be done.

In the refinement, let them give story points on the next batch of issues and fill the next sprint according to the feasible value (go to 80-90 %, with the message: if you're done earlier, you can get an additional item in from the backlog). 

Rinse-repeat this a couple of sprints and help them by divvying up the work into chunks that are "familiar" sized / complex, so that the whole team gets a feeling/ease with giving story points. This is the only way to get self-learning teams. 

Kind regards,

Dick

[Dick]

@Rashmi Ratnani 
So all in all, the plans are more for upper management, whereas the story points are something team-specific. All manipulation of story points by upper management, can only serve a high-over scenario's, certainly not an individual capacity per team member.

Sure, the two come together: when a team gets better at predicting the story points for certain backlogged issues, and a rough x story points can be dealt with by the team in one sprint, the team gets more predictable. Small disasters withstanding, of course :)

Predictable teams allow for a rough estimates of due dates to higher management. 

Kind regards,

Dick