Send the link below via email or IMCopy
Present to your audienceStart remote presentation
- Invited audience members will follow you as you navigate and present
- People invited to a presentation do not need a Prezi account
- This link expires 10 minutes after you close the presentation
- A maximum of 30 users can follow your presentation
- Learn more about this feature in our knowledge base article
Normalizing Story Points at Scale:
Transcript of Normalizing Story Points at Scale:
Why Are you messing with my story points?
What is a 'Story Point' in Scrum/Agile?
But HOW does that work for my
Program or Agile Release Train?
Story Points as a Unifying Concept
Use the estimation tool that the basic building block (the Team)
uses - Story Points
What's the Issue?
When Scaling from an agile team to an agile program
...AKA an Agile Release Train...
to an Agile Portfolio
Relative estimate of size and complexity.
Replaces Time Based Estimates
It is Unique to Each Team!
Because Each Team
is Responsible for
Estimating the work
it is going to commit
to delivering in the
What can we use to
estimate the amount
of work the Program
or Portfolio can commit
to for our next
Used Only for Planning!
Let's consider some aspects of our team as
it relates to sizing the work they do.
Agile Release Train
(team of teams)
Sets of ARTs
1 -4 week sprints
PSI 8-12 weeks
in 2 week increments
300+ people 3 - 100+ teams
6 - 12 Months
6 Month Rolling Wave
Epics and Features
Aggregate at each grouping - team , ART, Portfolio
Only use for planning at each level
Looking at it another way...
Normalizing story points for ARTs and value streams is not evil. It doesn't take away the team's ability to assess what they can commit to and it's not written in stone. Always check and make sure it is used for planning only.
Normalized Story Points
Common Language between