In traditional project management, project planning consists of identifying all of the underlying deliverables, activities, tasks and inter-dependencies that contribute to the project, estimating the effort associated with each of these, and then refining these into something that meets the overall goal (usually a predetermined date). This exercise can take weeks to complete even for comparatively small projects. Advocates of agile planning methods would assert that this is a total waste of time! Well, perhaps not so harshly. This is strongly argued however because the resulting plans are loaded with assumptions, and are highly inflexible in the face of changing or evolving requirements. So just as “No battle plan survives contact with the enemy”, so no pert-chart-based project plan survives it’s first project status review! Enter story points.
Story points give us a way to dramatically simplify the onerous and complex task of software project planning. Story points are applied both at the release and iteration level of planning. At the release level we use them to determine the amount of functionality that can be produced in a given timeframe. At the next level of planning we use them to estimate what subset of the release can be produced in each iteration.
Story point planning is based on estimating the relative size of each user story in a release. One of the most popular relative sizing scales is the Fibonacci series: 1, 2, 3, 5, 8, 13…Using this scale a ‘1’ is used for the smallest story. A ‘2’ story is twice as large as a ‘1’ story, and a ‘3’ story is as big as a ‘1’ and a ‘2’ combined. To put this in perspective, if the average story in an iteration takes a couple of days to complete, then it would be very unlikely that anything larger than a ’13’ would fit within a 2-week iteration, and would need to be broken down further.
A team’s velocity is then defined as:
Velocity is a measure of the team’s feature production capacity per iteration in story points. It is important to establish this as early as possible for a number of reasons. First, assuming that we are maintaining a reasonably well-groomed product backlog, so that the product owner can construct a release roadmap with reasonable estimates of the content of each release. Second, so that the team can quickly estimate the scope of both releases and iterations. And finally, so that the team can quickly understand the implications of change requests to a release plan. The team’s velocity can be established by running a few early sprints and identifying the actual functionality delivered in story points.
Using Story Points for Release Planning vs. Iteration Planning
- The planning horizon for a release is typically 3 to 6 months
- The planning horizon for an iteration is 2 to 4 weeks
- The level of planning granularity for a release is Epics/User Stories, with the User Stories estimated in Story Points
- The planning granularity for an Iteration is development/test tasks, with the estimates in hours
- Release planning is done at the beginning of a release
- Iteration planning is done at the beginning of each iteration
|Release Planning||Iteration Planning|
|Planning Horizon||3-6 Months||2-4 Weeks|
|Planning Granularity||Epics > Stories||Stories > Tasks|
|Estimation Scope||Story Sizing (Story Points)||Task Effort (Hours)|
|When Performed||Release Planning||Prior to Sprint|
|Who Performs||PO + Dev Team||Dev Team|
Team Velocity Determination
Select the proposed list of stories for the first iteration, or start with the prioritized release backlog. As a guide you should have a list of no more than 20 stories for a team of 5-7 people. Get the list on a whiteboard, spreadsheet (or your agile tool of choice), and get this in front of the team (on a whiteboard, projector, webex, gotomeeting, skype, etc.)
- Select a small story – it does not have to be the smallest – just one that looks reasonably well understood. Assign it a ‘1’
- Next find a story that looks roughly double the size of the prior story and assign it a ‘2’
- Proceed in the same way by identifying a ‘3’, a ‘5’ and an ‘8’. Think hard about stories bigger than ’13’. Consider breaking them down into smaller stories.
- Identify where the other stories fit using these stories as a reference until you have estimates for the entire list.
- Execute the sprint, and stick to you defined time-box (2-weeks, 3-weeks, etc)
- At the end of the sprint only count points for stories that get completely finished per your definition of done. At this point you should also revise any estimates that turned out different from the original. You can use these stories as reference stories going forward.
- Team velocity = total story points delivered
- Calibrate with 2 initial Sprints
- Team’s first sprint likely to include a 40% overhead (formin, stormin, normin…)
Velocity should be measured for every sprint and the trend should be closely monitored. Use retrospectives to identify opportunities for continually improving the team’s velocity.
Release Planning based on Team Velocity
Example (assume team has a velocity of 20):
- Project start: January 1
- Project finish: June 30
- Sprint length: 2 weeks
- Sprints required: 13 (26/2)
- Total story point capacity = 260 (13 * 20)
Let’s say the release planning estimates a total of 300 points to be delivered. In this example, the team is required to trim approximately 40 (low-priority) story points from the release backlog to meet the June 30 release date. If this is unacceptable, 2 more sprints must be added to deliver the additional 40 story points.
Release Planning with Story Points – Mechanics
- The team (PO + Team) gets together in a room with a whiteboard laid out as above, (or, via Webex, GoToMeeting, Skype etc with spreadsheet as above).
- Team identifies smallest stories and assigns them 1-point.
- Team members place Post-Its for each story in the appropriate story-point size column
- Stories > 13 points should be broken up into smaller stories
- Conflicting estimates for the same story are noted and discussed in detail to resolve.
- Do not attempt to plan more than 60-90 days worth of story development.
- A release should have no more than 20-30 epics
- For larger releases with multiple teams contributing, stories should be distributed between the teams, and each team independently produces the story point estimates.
Now here’s a question: could the above exercise be done asynchronously? Say the team members are distributed both geographically and across time zones. Could this process be done independently by each team member, or, in the case of multiple teams, by each team independently. That would not be the ideal approach, but alas, sometimes the only viable approach, so the answer is of course, yes.
Velocity-Based Iteration Planning
The output of the release planning step is a prioritized list of stories plus size estimates in story points. Iteration planning proceeds in 2 steps:
- Select user stories in priority order from the release plan and assign them to the iteration. Continue assigning stories until the total story points assigned matches the team’s velocity.
- Decompose each user story into the tasks required to develop and validate it, paying attention to the tasks required by your definition of ‘done’. In short, include every task needed to get a user story to a shippable state. Team members sign up for the tasks.
Tracking Releases and Iterations
- Release-level tracking: Burn-down story points
- Iteration-level tracking: Burn-down effort-hours
Arguably, once a team has established a stable velocity, the effort-hours task-level estimates could be dispensed with. The breakdown of stories into tasks at the iteration level is still required so that the work can be defined and allocated. But all that really matters is that the team has a high probability of delivering all required stories within the sprint boundary.
You can see a slide presentation of this topic here