This post is going to discuss some of the reasons that work within Sprints can end up incomplete. By this I mean that not all stories / tasks taken into a sprint are done by the end of of it, which means you do not have a potentially shippable iteration of your product / software — which is obviously a problem if this is your teams objective.
This is one of the most common issues within teams trying to use Scrum, and is often the reason that new Scrum Masters are brought in to sort it out. I obviously can’t provide a complete list of all possible causes, but I’ll cover some of the most common ones that I have seen.
Warning signs
Teams running (traditional) Scrum for a period of time should have an idea of what their velocity (number of story points completed per sprint) is. If you plot this on a graph it should look like a slightly wavy line:
Velocity will never be exactly consistent and you shouldn’t expect it to be. If it’s always exactly the same I’d be concerned that someone is massaging the numbers.
At the other end of the spectrum are velocities that look like mountain ranges. The Alps are a particularly beautiful range of mountains in Europe that are especially jagged in their appearance. The image below is from a bike race I did through a part of them showing the profile of the route:
If a teams velocity chart looks like this (and sometimes they do) it’s a classic sign that their process needs bringing under control.
Problem: Sprint commitment is too high
This is a pretty obvious one but strangely is often overlooked. If a team is taking too much into a sprint they will never complete everything, and the amount of work they do finish will be pot-luck. Most strangely of all, during sprint planning the members of the team will KNOW if they have a hope of completing everything or not, regardless of whether they are nodding their heads and saying “yes, OK”.
An unexpected cause
It may seem ridiculous for teams to say “yes” when they know the real answer is “not a hope in hell”. But most humans do not like conflict and will avoid it at all costs, and people in IT seem to be especially keen to try and be helpful — even if it causes problems further down the line. A Scrum Master (I really do hate that name) HAS to be aware of this and create a comfortable, safe environment for teams to be able to say what they really think / know. The Scrum Master may have to drag it out of them, but that is part of their job.
Solution
Take in less work!
If some items have been rolling over for several sprints you may need to have a whole sprint where you take in nothing new at all so that the team can catch up. There may be a reluctance to do this because of external / management pressures, but that is a false economy. If the team continues as it has been the situation is not going to improve, and it is the responsibility of the Scrum Master and Product Owner to push back on external demands in order to protect the team and allow them to function as well as they can. In reality this should be an easy sell — if management can see that there is a problem then they should be willing to get on board with the solution.
On it’s own though taking in less work may not be enough, as the work may not have been defined well enough in the first place. Which leads into the next problem…
Problem: Poor stories
Or in other words:
Crap in, crap out
One constant I’ve seen with numerous Scrum teams over the years is the very simple point that if you put crap (stories or tasks) into a sprint then you will get crap (results) out. How can you not? If you’re putting crap in and getting good results out then great, but you’re running on blind luck.
Creating a potentially shippable iteration within a 2 week sprint is possible, many teams do it all the time. But it takes a lot of discipline, and a key element of that is:
The team must have a clearly defined target of what they are aiming for.
Because if they don’t how will they ever complete the work in time, to a quality that is ready to release into production?
Solution
This is the reason that I defined a few basics in my last few posts, and the one I’m going to pick out here is the Definition of Ready. This ensures that any work taken into a sprint has been sufficiently analysed and broken down by the team so that there are no (significant) remaining questions about it. Sure there may be a few tweaks required here and there but all the big fundamental questions have been answered. This ensures that the team will be able to complete the work within the sprint. If not then the item needs to go back for further analysis, split into smaller items, rethinking, etc.
Having well defined stories or tasks going into a sprint is a big step to getting a team closer to completing their sprint commitment. But there still might be another piece to the puzzle, depending on on how the team itself is working in the sprint…
Problem: Too much Work In Progress (WIP)
It’s easy to end up with too many tasks in progress during a sprint: some individuals work faster than others, some items may get blocked waiting on an external dependency, someone says they need more work, and so on. The problem with this is that the team have lost focus on getting things done link- and by that I’m referring to the Definition of Done. It’s no use having lots of things “nearly done” at the end of a sprint as you can’t release that into production and your customer receives no benefit. A team might think that they’ll fix it next sprint, but in reality all that happens is that the same problems compound, and the overall situation gets even worse. It can get so bad that you end up with your testers carrying an entire sprints worth of debt (testing that they haven’t completed yet) — so what are the developers going to work on during that sprint?
A common problem here is that the team are working as individuals, not as a team. It’s quite likely that the developers are working on an item and then “throwing it over the fence” to test. That might seem fine but it means that the testers (through no fault of their own) are always going to be the long tail. If they’re given work 1–2 days just before the end of a sprint they have little chance of completing it all on time. In reality the team is just running mini-waterfall.
Solution
All team members (and in some cases especially developers) need to understand the fact that they are part of a team, there is no value in them completing “their” work when the team is not completing the sprint. To help address this I’ve found the idea of Squads a helpful way to deal with this problem.
Depending on the exact work involved a Squad is made up of one developer and one automation tester (because all your testing is automated, right?). When the Squad picks up a new item to work on they have a conversation called a “3 amigos” where they get together with the Product Owner (or BA) in order to go over the work and ensure that everyone has a common understanding. Why do this, when the item has already been refined and agreed? Refinement may have happened several weeks before, and the team members may have just finished another piece of work, so getting everyone together for a refresher can be very useful. Worst case you waste 5–10 minutes because everyone is on the same page, but you may find a small difference that saves you 2–3 (or more) days of development / test effort that then needs to be re-worked, so I feel that this more than justifies a quick 5–10 minute chat. Once this chat has happened and everyone is agreed then the developers and testers start work on the item at the same time. This massively reduces the opportunity that the developers will finish well ahead of the testers. The testers can use the same feature branch that the developers are working on, so they don’t need to lag behind waiting for a skeleton API / UI element definitions to be ready. The developers may not initially be working like this but in my experience it’s a small change for them and the benefits to the testers is huge because they can really get into the guts of the work much sooner, all of which helps the team with the initial goal of getting work completed, to the Definition of Done within a sprint. If the developers do finish much earlier than the testers (you can drill into the details of that in a retrospective) then they can try to help the testers finish their work — automation tests are code after all, and developers can write code so they can help. That can take a bit of a mindset shift and it’s not always practical to just throw more people at a problem, but even just getting them to sit together to pair program on the tests often saves time, as the developer can explain some of the more subtle complexities of the work, and another set of eyes on something is always useful.
A side note on this. It’s important that the Scrum Master shouldn’t force the idea of Squads (or anything else for that matter) onto the team, rather they should sit them down and ask them what the solution to the WIP problem is. The Scrum Master can then steer the team in the direction of squads if they don’t come up with a viable alternative on their own.
Summary
There probably isn’t just one reason for a team suffering from incomplete sprints, there are often several problems that need addressing, but you can see above how several reasons can all be related.
In an up-coming post I’ll take a look at other problems with Agile not working, specifically in the area of dependencies.
