Recognizing Bottlenecks in Scrum, Part 2

In my last post, I talked about the nature of product backlogs and said that they express the aggregate effect of bottlenecks that exist downstream in your system. Now I’ll give you some examples of bottlenecks and their patterns.

recognizing bottlenecks in product backlog scrum agile software development

1. Ill-defined product backlog items

Top-priority product backlog items are not well defined for the team to fill up at least their next sprint and start working. Too often this results in lengthy sprint planning meetings, and delay in terms of days before a scrum team makes a sprint commitment and gets going. In such cases the team spends the first few days of the sprint analyzing requirements, holding design sessions, etc., prior to making a sprint commitment. Sprints in this case go in fits and starts with a significant gap in software development efforts between the end of previous sprint and the start of new sprint. In this case the bottleneck is recognized as gaps between sprint end and start dates.

2. No product backlog items

In most cases, this situation is not an invalidation of the assumption that the business has more work than the team can do in a sprint. In fact, too often the business has a pressing need to get many features out of the door. A flood of information, lack of agreement, “have to get it right the first time” has a paralyzing effect, boxing the team in a state of limbo where product backlog items (PBIs) are not defined and the scrum team is left out to dry. Often the bottleneck in this case is upstream of the scrum development team, causing either an abrupt end to sprint rhythm or a false start with frequently extended ‘sprint 0′.

3. Not-Done product backlog items within a sprint

It is common understanding that PBIs within a sprint are either Done or Not-Done as measured against their definition of done. PBI’s that get Done are counted towards the team’s sprint velocity and the rest are not. Teams that end their sprints with some or many Not-Done PBIs find that their ability to pull in new PBIs in the next sprint is bottlenecked. Following the mechanics of good scrum practices, these teams present Not-Done PBI’s to the Product Owner and estimate remaining work for prioritization in Product Backlog. In my observations of these situations, the Product Owner will usually ask for Not-Done PBIs to be completed in following sprint. So the team effectively carries forward Not-Done PBIs from last sprint into the next sprint. In cases like these, it may feel like that there is a smooth flow from concept to realization, however it ain’t true. Look at the worst-case scenario – no new PBIs are pulled from the product backlog and the team spends the next sprint finishing up not-done work from the previous sprint. In this worst-case example, it is easy to call out such a bottleneck, but in real teams there are variations along the continuum of getting all committed PBIs Done to getting none of committed PBIs Done. It takes an experienced scrum team and/or ScrumMaster to recognize this pattern while its happening.

4. Insufficient infrastructure

Lack of staging environments, insufficient QA infrastructure and/or production-ready environments stop the flow of developed features at some point before these features can be deemed production-ready or ‘potentially shippable’. All these features pile up and aggregate until a sprint or two prior to release date. Then the teams make a major ‘push’ to release all of the developed functionality out of the door.

These last sprints are often called ‘stabilizing sprints’. And I have to say, I will start liking the term ‘Stabilizing sprint’ under the condition that all of the previous sprints are called destabilizing sprints. Each one of the previous sprints was destabilizing the product increment unpredictably. Sadly for me, most people interpret the term ‘Stabilizing Sprints’ as a good thing :( .

The tricky thing with all the hard stuff, like performance testing, regression testing, etc., that could not be done within regular sprints is that the hard stuff does not get simpler if it’s left for the last sprint. It gets even  more difficult. Causing a snowball effect. Take regression testing for example: If regression testing was not done in previous sprints, then a lot of regression bugs can show up. If these bugs cannot be fixed in the last stabilizing sprint, these will then ideally fuel the addition of PBIs to the product backlog, leading to either a lower quality or delayed product release. In either case, there in lack of objective perception regarding both quality and predictable release date. This bottleneck is obvious to everyone, for there are features piling up every sprint waiting to be production ready however the exponential negative impact is still underappreciated.

Creative Commons License
This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 United States License.