Table of Contents
Feature selection (sprint planning – part one)
Many teams set an overall goal for the iteration to help guide the selection of features. At the beginning of the meeting, the highest priority features are typically selected from the release plan. If the iteration does have an overarching goal, then some lower priority features may be selected if they better align with the goal. Prior velocity is critical to enabling the team to schedule a realistic amount of work.
For example, if the team previously planned to get 40 story points worth of product features, but only successfully delivered 30 story points, then 30 story points should be considered the current velocity for the next iteration. Past velocity estimates compared to actual numbers are useful at the iteration level, the feature level, and the task level. All of these help the team determine how much they can sign up for in the next iteration. If the iteration is overbooked, then the customer needs to select which features need to be delayed to a future iteration. During the iteration planning meeting, the customer will discuss features with the team and attempt to answer any questions the team has.
Task planning (sprint planning – part two)
The team will break the features down into tasks. Developers then sign up for tasks and estimate them. Tasks typically range in size from four hours to two days, with most tasks capable of being delivered within a day. Tasks larger than two days should generally be broken down into smaller tasks. Occasionally during task planning a feature is determined to be have been woefully underestimated in the original release plan. In this case, the team will need to work with the customer on providing a corrected estimate and determining what feature or features may need to be delayed as a result.
Iteration adjustments
During the iteration, if there is remaining time after all features have been delivered, then the team can request that the customer identify additional feature(s) to add to the iteration. If, on the other hand, it is obvious that not all features can be delivered, then the team works with the customer to determine which features could be delayed or perhaps split in order to deliver the most value by the iteration deadline.
Warning signs
- If over a series of iterations the team continues to push features out into the future, it is a sign that the team should pay closer attention to its prior velocity in order to minimize continuous overbooking and maximize planning accuracy.
- If the team keeps pushing the same features forward each iteration, it may be a signal that the team is purposely avoiding certain functionality and the root causes should be explored.
- If the team is diving into too much detail and designing each feature in full, there may be an opportunity for increased focus on identifying the task work that’s necessary.
FAQs
How do we handle dependencies between tasks?
This question comes up quite a bit. As part of iteration planning, the team should strive to minimize task dependencies as they divide features up. Specific techniques abound in Mike Cohn’s excellent book User Stories Applied. Next, the team should strive to collaborate to minimize the effects of unavoidable dependencies. Agile teams typically embrace simple, loosely-coupled, adaptable designs that minimize dependencies. An excellent resource for devising and refining such architectures is Bob Martin’s seminal book Agile Software Development: Principles, Patterns, and Practices. Agile teams also use techniques, tools, and practices that enable them to work concurrently on interdependent subsystems and modules. Test-driven development, automated test harnesses, and mock objects help teams minimize and cope with task interdependencies. Continuous, close collaboration can be key here; co-located teams find it easier to work out dependency challenges together throughout the iteration in a just-in-time fashion.
Iterations are only so long, reducing the risk that a single lurking dependency will kill the project. PERT charts and CPM, while potentially valuable in terms of general system understanding, have a very high tendency to crumble under the stress of high-speed, iterative software development. The additional time and effort spent to build a dependency model for a two-week iteration is rarely worth the time. Automated tests and code will give you more accurate, executable feedback at least as quickly.
How much should a team member sign up for?
A team member should rarely sign up for more than the total estimate of the tasks they were able to complete in the prior iteration. If tasks are not being signed up for during iteration planning, then more emphasis is placed on making sure the team does not sign up for too much work by comparing to the prior iteration’s feature and task velocity.
How do you plan iterations if team size varies?
Without the ability to rely on consistent team effort, no project approach, agile or otherwise, provides much insight. With iterative software development, though, at least there is typically some history that is built up over time to use as a basis for planning. With iterative development, if you have delivered several iterations with a team of ten with an average velocity of 20 ideal days or 200 hours per iteration, and your team is cut in half, then a simple calculation should lead you to plan no more than ten ideal days for the upcoming iteration (at least initially). If key personnel have been removed, or you find you are wrong, you will find out within the next few weeks and be able to quickly adjust for future iterations.
How do you account for overhead (meetings, email, etc.)?
Teams generally do not spend much time tracking minor overhead items. Over the course of a few iterations, these interruptions are reflected in increasingly consistent (if unexpected) velocity actuals. Some teams incorporate larger interruptions and disruptions into their iteration plans explicitly, to reduce risk and increase visibility.
How do you account for bug fixing during iteration planning?
There are a couple of ways teams deal with bug fixing. One of the simplest is to include bugs as explicit input to iteration planning, prioritizing it, and estimating the tasks involved. Bugs and features are essentially equivalent units of work for planning purposes. Some teams elect to track bugs separately outside of their iteration process. This is somewhat riskier: if the bug-fixing effort varies between iterations, then the team’s velocity will vary accordingly, throwing off estimates and plans. But if the bug-fixing effort is held constant, then this method can work reasonably well.
Why should iterations always be the same length?
Iterations with the same or very close lengths provide a rhythm that teams rely upon for estimating and planning. Without fixed-length iterations, it can be difficult to achieve and measure steady velocity. The discipline of cutting off production at the close of an iteration focuses everyone’s minds, applying pressure to keep designs simple and resist gold-plating or scope creep. The entire organization quickly grows accustomed to a steady hum of input, planning, execution, output, and retrospection. Without this rhythm, the team is less efficient. There will occasionally be good reasons to stretch or compress specific iterations, to fit them around deadlines, major interruptions, or holidays. But these should be the exception, not the rule.
How do I account for testing and documentation time?
Testing and documentation updates should be prioritized, estimated, and planned just like any other major activity that requires a developer’s time. They are often created as tasks under specific features, but may also be grouped as their own feature.
Should feature estimates be revised during iteration planning?
Feature estimates should only be revised during iteration planning if the original estimate is found to be way off base and the new level of effort will have a significant impact on the team’s ability to complete other work.
Should task estimates be revised during an iteration?
The original task estimate should not be revised once the iteration planning has been completed. On the other hand, the estimates for future iterations should be continually revised to reflect an accurate assessment of remaining work.
Should all teams operate on the same iteration schedule?
There are advantages to having all teams working on the same iteration schedule. Rolling up iteration status across teams is only meaningful if the teams are on the same schedule. It is not helpful to roll up any numerical status across a team that is just beginning its iteration along with another that is about to finish. The disadvantage to having all teams on the same iteration schedule lies in starting up and wrapping up iterations all at the same time. If common resources (e.g. a customer or management) are shared across projects, they may appreciate a staggered iteration schedule across teams.
