Small is beautiful for product backlog items

 

One of the reasons for having small work items at the top of a product backlog is so the team is able to complete them within a short amount of time. This benefit applies regardless of whether your team is using an iteration-based delivery approach or has adopted a lean continuous flow-based approach.

But what are some of the other benefits of having small work items?

• While size does not always positively correlate with complexity, usually the smaller a work item, the easier it should be for team members to come to a shared understanding with the work item originator as to what is desired and how they will deliver it.
• Smaller work items often require less documentation than larger ones.
• It might be less challenging for team members who are new to test driven development to apply this practice for small work items.
• If the team is using an iteration-based approach, the probability of getting a higher percentage of completed work items is greater if they forecast a larger number of small work items in an iteration as opposed to a smaller number of large ones.
• The amount of re-work or wasted effort involved if a particular work item does not meet general or quality requirements should be lower.
• If most work items for a release are small “enough”, the team has the ability to skip the use of story points or some other relative sizing method in favor of just tracking how many work items they can complete within a given amount of time.
• Finally, splitting a large work item into small pieces provides greater feature choice to product owners when prioritizing the backlog.

But before slicing our work items too small, we need to remember that size is just one of the criteria provided by Bill Wake when he came up with the INVEST acronym for assessing how good a story is. A work item which is too small might not be sufficient independent or provide value to a stakeholder.

But keeping these caveats in mind, good things come in small packages.