Our stories aren't getting done!

From the Easy in theory, difficult in practice Blog
by
My musings on project management, project portfolio management and change management. I'm a firm believer that a pragmatic approach to organizational change that addresses process & technology, but primarily, people will maximize chances for success. This blog contains articles which I've previously written and published as well as new content.

About this Blog

RSS

Recent Posts

What are some of the underlying causes of ineffective project risk management?

PMI plus Disciplined Agile might be a marriage made in Heaven

How open are YOU to changing your launch plans?

Does closeout vary between projects following an adaptive rather than a predictive life cycle?

Our stories aren't getting done!


Categories: Agile, Project Management


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.

 

Posted on: August 18, 2019 10:41 AM | Permalink

Comments (4)

Please login or join to subscribe to this item
Good Points Kiron. While there is no silver bullet, shorter sprint are definitely better as feedback is faster.

Three cheers for empiricism! Good read. Thanks.

I've worked on a continuous flow team and it is a joy. But I've also been on a team that wasn't quite ready for that, and the sprints were too short. Besides the fact that they regularly missed their sprint goals, the scrum ceremonies took too much of their time (it becomes difficult to time-box planning sessions as they get shorter and shorter), and they never had the slack to simply innovate.

There are warning signs to help determine if sprints are too long or too short, but it seems like teams will naturally resist changes to their iterations once they establish a cadence. This has been a real challenge for me.

Really strong points. Definitely have had to work through these challenges, more than once. Just when the team works in some new techniques to better handle, something new comes into the picture. That's just part of the show. It is the recognition and dialogue that sparks solutions.

Please Login/Register to leave a comment.

ADVERTISEMENTS

"I am not bound to please thee with my answer."

- William Shakespeare

ADVERTISEMENT

Sponsors

Vendor Events

See all Vendor Events