Contrary to some common misperceptions, agile is a highly disciplined and rigorous framework for developing software. Like any other disciplined undertaking, agile requires solid planning. Agile planning is however fundamentally different from traditional waterfall planning. As previously discussed, in the waterfall model, a development plan and schedule involves decomposing each requirement for the release into a set of tasks and then making estimates for the effort required for every task. For even modestly scoped commercial software projects the number of tasks could range from hundreds to thousands, and it is clear to most that these plans quickly become of out of date and need a huge amount of effort to maintain. Agile planning on the other hand is designed to be adaptive. The principles behind this approach are: 1) plans should only be as detailed as the depth of information currently available, and 2) planning must be continuously adjusted as improved project knowledge becomes available. Agile teams should be prepared to make planning adjustments as information about requirements, design constraints and the team’s velocity improves.
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
Contrary to some common misperceptions, agile is a highly disciplined and rigorous framework for developing software. Like any other disciplined undertaking, agile requires solid planning. Agile planning is however fundamentally different from traditional waterfall planning. The difference being that agile planning is adaptive. The principles behind agile planning are: 1) plans should only be as detailed as the depth of information currently available, and 2) planning must be continuously adjusted as improved project knowledge becomes available. Agile teams should be prepared to make planning adjustments as information about requirements, design constraints and the team’s velocity improves.
Agile planning occurs at a number of levels: Product Backlog > Product Roadmap > Release Backlog > Iteration Backlog.
Figure 1. Agile Planning
Product Backlog. This is the list of every conceivable requirement, feature request, enhancement, and wish-list item for the product. This list is derived from a variety of sources, including, product management, sales and marketing, customers, engineering, customer support, and virtually anyone who feels they have a stake in the product. Some organizations may have instituted a “Requirements Management” process, where requirements are processed through a formal workflow, with state-transitions like: submitted > accepted/rejected > approved, for reviewing and then accepting or rejecting proposed requirements. This results in a ‘groomed’ product backlog. Regardless of the degree of formality with which this is done, product management owns the backlog and is responsible for its grooming and prioritization.
Product Roadmap. For reasons of budget, engineering resources, market windows, and other constraints, not all product features can (or should) be delivered in a single release. Therefore a plan is required showing how features in the product backlog will be brought to market over a series of product releases. This high-level plan is usually referred to as the product roadmap. The product roadmap shows how major new product capabilities get rolled out over time, with the time increments usually at the calendar quarter level of granularity. The release content for each release is usually stated in terms of major product functions, not user stories.
Figure 2. A Product Roadmap
The product roadmap will be validated by discussions with customers on the one hand to get the priorities right, and internal stakeholders on the other hand to confirm the technical and budgetary feasibility of delivering in the advertized timeframes. The product backlog is constantly revised and updated as customer and market requirements continue to evolve.
Release Planning. Release planning is the most challenging part of the agile planning framework. The literature is full of confusing and contradictory advice. So I will attempt to be very precise about what release planning means and how it should be done.
The product backlog should contain a list of customer-facing “features”, where a feature describes a user-observable function of the product. Features are described in the language of sales & marketing staff, product managers and business executives, and are the things we would find in the marketing brochure or product data sheet for the product. Since major product features can rarely be delivered in a single iteration, they are usually decomposed into multiple user stories, spanning multiple iterations. In agile terminology, features are “Epics”. One example of an epic, and its constituent user stories could be the following User Administration epic:
Figure 3. Epics decomposed into User Stories
One of the fundamental differences between agile and traditional software planning is that with agile, the schedule and resources are fixed, and the scope is the one variable to be estimated. In addition to this we typically plan releases around a regular release tempo with, say, a release every 90 days (the releases do not actually have to go out the door). So the planning challenge for the team is simplified: what is the set of features that can be delivered in the next release cycle. It is explicitly understood that the scope the team estimates is going to be just that – an estimate. The planning exercise is helped by the fact that the product feature backlog is prioritized, and the scoping takes this into account. The estimation process does not consist of breaking each user story down into its constituent tasks and estimating effort for each task – that level of planning only occurs at the iteration level. The estimates derived in release-level planning are based on 2 things: a) estimating the relative sizes of each story (in story-points or other equivalent sizing measure, and b) knowledge of the team’s velocity – the number of story-points the team can deliver per iteration. The result of this exercise is a plan that may be presented as follows:
Figure 4. Release Plan
The broader team as a whole must commit to this plan (planning is not a game between the engineers and product manager or the marketing team). The team will next have to allocate individual user stories to each iteration in the release based on known production capacity per iteration (if the team does not have a calibrated velocity, there are some other steps that can be taken to get things moving. This will be covered in another article).
The entire planning process should take 1-2 days depending on the size of the release. This assumes appropriate preparation has been done: Product Owners – groomed and prioritized backlog; Team – Features/Epics broken down into User Stories.
Iteration Planning. Let’s summarize where we are so far. When release planning is complete we should have the following:
- Epics (product features) decomposed into User Stories
- Size estimates done for each story (Fibonacci, T-shirt sizes, etc)
- Stories allocated to iterations based on iteration length and team velocity
The next step is to define the development and testing tasks required to complete each story. To do this you need to have a clear definition of ‘Done’ for user stories. Here is an example:
- Code completed and checked in to the SCM system
- System builds without error
- Product daily or continuous regression completed without error
- Static analysis has no warnings
- Unit test complete and automated
- Code review complete
- Zero outstanding defects against the user story
- Product owner has accepted the story
We go to these lengths because the goal is to get each user story to a shippable state, and not to accumulate re-work. That’s what being agile means. Some people are quite shocked when they hear this. Let me put it another way:
As the team approaches the start of the next iteration, the next level of planning must be tackled. Iteration planning gets us down to a level of detail where each user story is broken into the development and other tasks that must be completed to get the story to ‘Done’. Let’s go back to our earlier example from release planning, and add the required tasks to implement the first user story:
Figure 5. User Stories decomposed into tasks
For each task, we need an estimate (in hours, using 2 days as a guideline for the upper limit for a task), and we need an owner. When the above chart has been completed for all user stories, and we can re-confirm that all of the work will fit within the iteration boundaries, then we have an iteration plan. For tracking purposes, we can track the overall release by burning down story-points, and we can track the progress of an iteration by burning down hours (More on this in a subsequent article).