On the seventh day of Christmas, my true blog gave to me:

Seven most-heard retrospective comments,
Six Keystone config tips,
Five Golden Rules!
Four CI tools,
Three powershell scripts,
Two Keystone merge tips,
…and a placeholder rule in the content tree.

Over the years, I’ve sat in a lot of sprint retrospectives. Below are some of the most-heard comments that might help you optimize your flow before you even see the problems!

1. <Somebody> is a bottleneck

I’ve rarely seen a sprint where work wasn’t piling up in one state or another in the process. Maybe there are too many requirement changes happening for the Product Owner to keep up, or maybe the developers are building too much for the testers to handle, or maybe the deployments are just taking too long to get stuff to the testers.

Optimizing the balance of the team to allow for continuous flow is a tricky but essential piece of agile delivery. Consider implementing Work-in-Process (WIP) limits to force the team to help other team members out who might be overloaded.

2. The requirements are unclear

I have seen our teams try minimal details, extreme levels of detail, and everything in between but still the team usually feels something is unclear. From what I’ve learned, it doesn’t matter what you document on the stories, nothing beats a walkthrough with the product owner.

My suggestion is to let the team flesh out the stories with the details that make sense to them, but make sure each member has a chance to talk it out. A visual demo of the flow is often the most helpful.

3. Our velocity needs to be higher

It may be related to the nature of our engagements, but our teams are usually locked into fixed scope projects. This means our teams need to hit a certain average velocity to get it all done. When the team doesn’t hit that average, the sprint retrospective often focuses on what impediments are keeping the velocity down.

You can’t really avoid this, as the teams will always want to optimize, but what you want to do is make sure you come prepared to the retrospective armed with a list of inefficiencies you’ve seen during the sprint. Maybe it was too many manual deployments, maybe there was too much churn on requirements, whatever it may be, identify and adapt!

4. We’re waiting on <Some Third Party>

I can’t count the number of times I’ve seen a retrospective bring up the fact that the turnaround time on getting something from a third party group is taking too long. As soon as other groups start coming into play, you can probably throw any idea of a predictable timeline out the window.

Ideally, you can work with stubs of any third-party dependencies to keep progressing while you wait, but at some point these dependent technologies or work products are going to be needed. I usually suggest tagging stories that have these types of dependencies so you can tackle them early. Trying to complete these type of risky stories late in the project won’t leave you with much time for delays.

5. Working on VMs is so slow!

This one is probably more relevant for consultants and contractors. Often we are placed in a position where we need to work inside the client’s environment and there is no way to punch a hole through the firewall for our own devices. This means working in virtual environments, typically over Remote Desktop, with all the headaches that ensue.

If you are about to embark on a project, try to see if there is any way to avoid this scenario. Your team has optimized their local setup for efficient delivery and working in a foreign environment over remote connection is just hurting the team’s ability to deliver.

6. Too many blocked stories

When impediments come up, stories get blocked and can’t progress. If this happens too often in rapid succession, the current sprint can grind to a halt and it will be difficult to finish the planned workload. Team members also have difficulty finding another work item when it seems like everything is blocked.

Somebody, usually the person playing the role of Scrum Master or its equivalent, needs to be keeping an eye on this and reacting as quickly as possible. Consider increasing the number of people working on unblocking stories if things are piling up.

7. The stories don’t seem “ready”

This is similar to the requirements being unclear, but uncovers a different problem. This feedback from the team is usually an indication that not only do the requirements seem unclear, but it doesn’t even look like it was meant to be worked on yet.  Common indicators:

• Missing visuals
• Incomplete acceptance criteria
• Unanswered questions/TBDs in the description
• No estimates on the story
• Contradictory information

I’ve seen this occur when stories get added into the sprint to let the developers start on it but the Product Owner hasn’t had time to finish up all the work on it yet. If a conversation-based approach is intended, that can sometimes work, but often the confusion leads to a lack of confidence in the current sprint backlog being “ready”. My preference here is to never add a story to the sprint backlog until you are sure that open questions are answered, you know what the acceptance criteria is, and you can estimate the story.