Our stories aren’t getting done!

It is common to see teams new to those agile frameworks which use time boxes struggling to define product backlog items small enough to get completed within a sprint and still represent value. If they have been used to traditional, predictive delivery approaches, they would have been encouraged to decompose scope down to a manageable level of control, but these work packages would still usually be larger than what is expected of a sprint backlog item.

Some teams respond to this challenge by using long sprints.

While this gives them the opportunity to complete more work within a sprint, it has downsides. The team might be inclined to batch their work by completing one stage of their delivery process for a number of sprint backlog items rather than completing these items individually over the life of the sprint. Long sprints might also reduce the team’s inclination to sufficiently refine and split stories.

Other teams try to avoid the challenge entirely by skipping sprints in favor of a continuous flow approach. A mature team can effectively use this delivery method, but new teams without coaching support might end up with an ever-growing work-in-progress backlog as work commences on a work item but as soon as it gets blocked another work item gets pulled.

Shorter sprints make it harder for a team to ignore the reasons for why their work items aren’t getting done, including:

• Vagueness or ambiguity with the work item. If the team accepts the work item into a sprint without shared understanding on what is required, significant effort can be spent in gaining that understanding or in doing rework if their original understanding wasn’t complete. This can often be addressed through effective look ahead planning a sprint before that work item is accepted by the team.
• Underestimating the size of the work item. While occasional under or overestimation are common cause variations for mature teams working on a product which they are comfortable with, chronic underestimation might point to over-optimism or a lack of sufficient diversity within the team.
• Lots of external dependencies. The effort of the team for work items might be manageable but if they are relying on external partners for some of the work, they may not have sufficient influence over these partners to ensure that the work can get completed on time. If this is the case for a few product backlog items, it might be something they have to live with in the near term, but if it is happening every sprint, it shows they are not truly a “whole” team.
• Excessive multitasking. Whether it is distractions from outside the team’s product work or it is taking on multiple work items at the same time, context-switching can rob the team of the ability to complete a single work item in a short amount of time.

While there is no silver bullet to deal with these causes, if a team remains true to the pillars of inspection and adaptation, their ability to deliver consistently should improve over time.