Small Items

... a Scrum Team is regularly creating product increments where the ordering of the Product Backlog is based on several factors, most of which are not fully understood at the time of the ordering. For example, the work required to complete a Product Backlog Item (PBI) is unknown before it is completed. In addition, the value created by the Product Backlog Item is also unknown beforehand.

✥       ✥       ✥ 

Big ideas are great to have but the devil is in the detail.

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, large Product Backlog Items are more difficult to communicate and understand and this 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 work together and the Product Backlog is the nexus for this work, so it must comprise items that support communication and understanding.

Whether a large item has voluminous information or absence of detail, the large items carry with them a large amount of risk. If the item is a big and vague idea, successful implementation is nigh on impossible and will have the Development Team re-working any implementation they create. This is obviously wasteful. If the large item conveys a large amount of information (such as scenarios or acceptance criteria) the Development Team is at an increased risk to complete all of the specified requirements within a Sprint. Both of these scenarios are common for Scrum Teams, the former is often caused by a lack of engagement of the Product Owner with the Development Team, or when a Development Team is forced to “wing it” with whatever information they have. If waterfall style delivery habits are still strong in the team, there may be good engagement as the team discusses some increment with broad scope, but everything is documented and everything is needed.

Attempting to estimate large items increases variance and errors into the estimate. [1] By definition, an estimate is a guess, so it is imperfect. We know when we measure anything the measurement we obtain is a combination of the actual value and some amount error, for estimates we can expect the error component to be large and wildly varying between estimates. If this error is 20% (probably a relatively small error value) then for a large item this error proportionally larger than a small item being estimated e.g. an estimate of a large item at 20 days has an error of 4 days, where as an estimate of smaller item at 5 days has an error of 1 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 larger items are more difficult to understand this will create a larger 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 which may be dealt with via contingency but 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 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 product is with respect to the Product Backlog or Roadmap; the position is a guess until the product is made.

The habit of hoarding work or defending your own ability to get it done can be strong and difficult to change in many organizational cultures. In these cultures the effort to have smaller SBIs may not be viewed as worth the reward. If a Development Team creates Sprint Backlog Items (SBIs) that are large, such that these take many days within a Sprint to complete, 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 Sprint Backlog Items (not bringing them to Done), even if they are almost Done, they have a large impact on the ability to meet the Sprint Goal and deliver value. The team sees that their small incompletions have large consequences.

The root problem of this symptom is misunderstanding of the PBIs/SBIs by the Scrum Team. They 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 work required. However, we need estimates to be reasonably accurate at the aggregate level, because we use them to plan. If estimates cannot be relied on, one cannot rely on the plans either. Actually, estimates are a gauge of our understanding of the item: if estimates are wildly inaccurate, it is an indicator that we don’t understand the item well enough to develop it. In the case of PBIs inaccurate estimates may hamper ordering it against other PBIs.

Large items are by nature hard to understand, estimate, and reliably deliver.


Have small items that are steps to deliver the big ideas, where each small items is easily understood and can be completed by the Development Team.

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 2 days of work from start to Done (see Definition of Done), the time frame is arbitrary and depends on your planning horizon but for sound implementation of this pattern should be taken as a maximum time. Though we strongly recommend use relative estimation (see Estimation Points) for PBIs and not time based estimation a Development Team will develop a “feel” for what can be achieved in what time frame and this pattern 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] 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 the team understands the items thoroughly so they can deliver them reliably first and improve forecasting second. The aggregated 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 traditional product development practices are driven by estimates, particularly estimates of cost. 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 improves understanding of 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 increased opportunity for 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 delivery. This level of engagement may require the Product Owners to have support in their role to cover all the work required to be effective (see Product Owner Team) but the benefits of this situation should clearly outweigh the extra cost.

Using Small Items in the Sprint Backlog helps reduce the “leakage” resulting from failing to deliver any particular SBI. Using Small Items in the Product Backlog gives insight into PBIs earlier so they can be brought to Ready and are more likely to constitute an Enabling Specification. Focus on items at the top of the Product Backlog as described in Granularity Gradient.

Some teams that have adopted Small Items have found there to be extra effort in managing 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 this is often related to the tool teams have adopted to help manage their backlog, where having more SBIs than team members seems to be a threshold of where the effort to use the tool is greater than the benefit the tool provides. Using sticky notes for SBIs rather than an online tool seems to resolve this tool problem.

Jeff Sutherland reports observing a significant decrease in story points delivered as the size of the PBIs increased.

[1] Adam Trendowicz and Ross Jeffery. Software Project Effort Estimation. 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, pp. 3-16.

Picture from: