...a Scrum Team is regularly creating product increments where many factors influence the ordering of the Product Backlog, and the team may not perfectly understand these factors when ordering the backlog. For example, the Development Team doesn’t know the exact amount of work required to complete a Product Backlog Item (PBI) until they complete it. In addition, the Product Owner cannot pinpoint how much value a new Product Backlog Item will create over its lifetime.
✥ ✥ ✥
Big ideas are great to have but the devil is in the details.
It can be very easy to have big ideas and use these to make up a Product Backlog. Big ideas have their place in Scrum (as a Vision) and to some extent in the Product Backlog (Granularity Gradient). However, it is more difficult for the entire team to concisely conceptualize large Product Backlog Items, which can limit the Product Owner’s ability to relate them as an Enabling Specification to the Developers. Communication and understanding are key for the Product Owner and Development Team to be able to work together. The Product Backlog is the nexus for this work, so it must comprise items that support communication and building shared understanding.
Whether a large item has too much information or too little detail, it carries high risk. If the item is a big and vague idea, successful implementation is almost impossible, which may lead to endless rework by the Development Team. This is obviously wasteful. If the large item conveys a large amount of information (such as scenarios or acceptance criteria), the Development Team risks not completing the work for all the specified requirements within a Sprint. Both of these are common scenarios for Scrum Teams. The Development Team may be starved for information if it interacts with the Product Owner too infrequently or too superficially. Circumstances may force the Development Team to “wing it” with whatever information it has.
Increasing the size of work items increases variance and errors in their estimates ([1], p. 142.) By definition, an estimate is a guess, so it is imperfect. We know when we measure anything that the measurement we obtain is a combination of the actual value and some error amount. For estimates (which are not measured), we can expect the error component to be large and wildly varying for different items. If this error is 20 percent (probably a relatively small error value), then for a large item this error is proportionally larger than for a small item. For example, an estimate of a large item at 20 days has an error of four days, whereas an estimate of a smaller item at five days has an error of only one day. It is unlikely that the error of an estimate will be the same between larger and smaller items or between any two items we have in a Product Backlog or Sprint Backlog. As described above, it is more difficult for developers to thoroughly understand larger items, which may result in a larger percentage error in the estimate. If we add up the estimates across the Product Backlog (for a Release Plan), then we are adding these errors together. We can always correct this with some kind of padding or other contingency, and we can complicate the estimation regimen to reduce the risk of missing deadlines—at the expense of precision. A better tack may be to deliver a version of the product rather than spend all the time planning.
Feedback is an essential part of Scrum; the Sprint Review is a formal opportunity for the Scrum Team to gain feedback on progress of the product. The Sprint Review is most effective at providing this feedback when there is a potentially shippable Product Increment. Working with large items can limit the opportunity for the Development Team to finish this Product Increment, giving the Scrum Team nothing to review. This greatly limits feedback, which is the lifeblood of an agile team, because the product is in a state between planning and delivery—a nowhere land. Moreover, apart from feedback, this state gives no visibility about progress because the Scrum Team cannot really know where the product is with respect to the Product Backlog or Roadmap; the position is a guess until deployment.
The habit of hoarding work or defending one’s ability to finish it can be strong and difficult to change in many organizational cultures. These cultures may not view the effort to make smaller Sprint Backlog Items (SBIs) as worth the benefit. If a Development Team creates SBIs that are so large that each one takes many days to complete during the Sprint, the Daily Scrum becomes a pointless ritual. With no visibility of progress or changes in direction, the Daily Scrum may as well become a daily group hug (except that a hug may be a better use of the time).
When the team fails to deliver SBIs (not bringing them to Done: see Definition of Done), even if the team is “almost Done,” it will struggle to meet the Sprint Goal and to deliver value. The team finds that its small incompletions have large consequences. This symptom most often points to the deeper problem of the Scrum Team’s misunderstanding of the PBIs/SBIs. The team might not understand the magnitude of the work required or the risks involved. In addition, the team might not understand the PBI itself.
Teams generally estimate required work in terms of detailed sizing of individual tasks. However, the Scrum Team needs reasonably accurate aggregate estimates for release planning. If the team cannot rely on estimates, it cannot rely on the plans either. Actually, estimates are a gauge of how well the Development Team understands a given item: if estimates are wildly inaccurate, it is an indicator that the team doesn’t understand the item well enough to develop it. An inaccurately estimated PBI may be difficult to order against other PBIs, as estimated value and ROI (see Value and ROI) reflect the union of both the commercial value and the estimate effort to deliver.
Large items are by nature hard to understand, estimate, and reliably deliver.
Therefore:
Break work down into Small Items that are steps to deliver the big ideas, so the Development Team can master its understanding of each small item individually. Large items cloud understanding of important details, and misunderstanding causes surprises. The team can reduce schedule surprises by administering and working on Small Items.
A Small Item is a Product Backlog Item (PBI) or Sprint Backlog Item (SBI) the Development Team can easily understand and quickly (in the case of PBI) take to Done. “Quickly” for an SBI means within two days of work from start to Done; the time frame is arbitrary and depends on your planning horizon, but for sound implementation of this pattern, two days is a recommended maximum. Though we strongly recommend using relative estimation (see Estimation Points) for PBIs, rather than time-based estimation, a Development Team will develop a feel for what it can achieve in a given time frame; setting the two-day limit taps into that experience.
Estimating smaller items benefits from the law of large numbers and is better-suited to complex and uncertain work than is top-down estimation ([1], p. 142). Estimation expert Magne Jørgensen recommends that for new projects developed by experts in the field, bottom-up estimation works best ([2]).
Breaking items down helps us understand dependencies between items. For example, if you have two items that depend on each other, you can decompose each into smaller items that break the circular dependency. This can give the Product Owner more freedom in ordering the Product Backlog, and can allow more flexible ordering of SBIs in a Sprint.
Having smaller and better understood items to estimate will increase overall estimation accuracy and precision. However, the goal of this pattern is not to produce highly precise estimates. One must still play the game of estimating for the process to work: namely, to understand the item well enough to implement it correctly. The major output of this pattern is that team members understand the items thoroughly so they can deliver them reliably first and improve forecasting second. The aggregate estimate is useful in making a Release Plan and also during Sprint Planning.
We are more interested in combined estimates of items and trends over time than in estimates of individual items.
To have Small Items, a Scrum Team needs to spend more time on refinement of the Product Backlog with an increased focus on design of the product. As a consequence there will be less time on estimation. Scrum Teams and organizations new to Scrum will find this unnerving as estimates—particularly of cost—drive traditional product development practice. With greater flow that can come with Small Items there is a significantly lower risk of a Development Team not delivering a PBI, and this will stabilize cost (which becomes the cost of a Sprint), so the driving force for product development must be value or customer outcome rather than cost to deliver. This is a cultural change in product development that will require support for its implementation.
Breaking down large PBIs and SBIs helps developers understand them, because it necessarily involves design work. Small Items help the team increase the likelihood that it will achieve its forecast.
✥ ✥ ✥
Small Items in a Product Backlog allows for more regular delivery and better feedback on product direction. As well as creating opportunities to adjust the product to maximize value, the Product Owner must be actively engaged with the Scrum Team and the product to take full advantage of feedback. This level of engagement may require the Product Owners to have support of a Product Owner Team to cover all required work, but the benefits of this situation should clearly outweigh the extra cost.
Using Small Items in the Sprint Backlog helps reduce the “leakage” that results from failing to deliver any particular SBI. Using Small Items in the Product Backlog gives insight into PBIs earlier so the team can bring them to Ready (see Definition of Ready), increasing the chance that they become truly Enabling Specifications. Focus on items at the top of the Product Backlog as described in Granularity Gradient.
Some teams that have adopted Small Items have found it takes more work to manage the larger number of items in the Product Backlog or Sprint Backlog. Granularity Gradient helps remedy this problem for PBIs. In the case of SBIs, the blame often lies with the tool teams have adopted to help manage their backlog. Using sticky notes for SBIs rather than an online tool seems to resolve this tool problem.
Jeff Sutherland reports observing a significant decrease in Estimation Points (story points) delivered as the size of the PBIs increased.
[1] Adam Trendowicz and Ross Jeffery. Software Project Effort Estimation: Foundations and Best Practice Guidelines for Success. Basil, Switzerland: Springer International Publishing, 2014, p. 142.
[2] Magne Jørgensen. “Top-down and bottom-up expert estimation of software development effort.” In Information Software Technology (46)1, 2004, pp. 3-16.
Picture credits: Shutterstock.com.