I think this post is more about personal catharsis than anything else, but hopefully there is something useful here.
I recently introduced a work-in-progress (WIP) limit with a Scrum team and was delighted that the average cycle time on user stories was its lowest ever for the team and several times lower than the overall average.
The team delivered everything that was planned for the sprint as well as tackling a significant technical debt and successfully increasing unit test coverage by a target percentage.
When it came to the retrospective, I expected nothing other than glowing pride in the team’s achievements.
But I was wrong!
There were several criticisms:
- comparing the cycle times in this sprint to previous sprints is like comparing apples and oranges, because we broke down the stories into much smaller pieces
- the functionality delivered was small and breaking a feature into smaller user stories means the whole feature takes longer to do
- the WIP limit was too low because there was “idle time”
Wow! Quite a lot of criticism! Not all feedback was negative. The team also found some benefits to what we had done, but the Product Owner was the least happy.
Let’s look at these objections:
Comparing the cycle times in this sprint to previous sprints is like comparing apples and oranges, because we broke down the stories into much smaller pieces:
There are some mistaken assumptions in this statement. I have found it quite common for people to assume that Agile is all about “working faster”. This is a dangerous assumption, because it is simplistic. Honestly speaking, we should not expect developers to code significantly any faster than they already do. Coding takes time and thought, that is a fact.
No, what I expect teams to do is to work smarter, so that the considerable effort put in yields more in return. By celebrating cycle times several times lower than before, we are not claiming that the developers are suddenly typing four times faster! What we are saying is that the team has successfully delivered a slice of complete, good quality code which is useful to the customer and we can be confident that everything needed was done and we don’t need to go back to it to finish it off. We can also be confident that all of the team’s effort was focused on this user story and was not wasted on work which was not useful.
The functionality delivered was small and breaking a feature into smaller user stories means the whole feature takes longer to do:
It is interesting to think about the underlying assumptions here. Firstly all the stories which were planned were delivered within the sprint. In the sprint planning, we estimated each story just as usual and used our typical velocity to decide how many stories to bring into the sprint. What did happen in the sprint planning was that large stories were broken down and not all of the large stories made the cut, because there was too much. I think this was a case of the Product Owner wanting to put big stories in and not getting them in, whereas in the past, the big stories would have been brought in and then run over two or more sprints. This is where Scrumnesia kicks in. Once a big story is completed, it is sometimes forgotten that nothing was delivered in the previous two sprints! So, by breaking things down and making the size of the work more transparent, the output appeared worse! But I believe this was an illusion.
The WIP limit was too low because there was “idle time”:
I accept that the WIP limit may need to be adjusted up or down to get the right throughput, but I would question the assumption that “idle time” is a bad thing. I think that keeping a sustainable pace is important, and to do this, developers need time to gather their thoughts, they need head space for creative thinking, they need time to review code, to do a little tech debt, to help each other out and to learn. Working relentlessly on user stories is not sustainable in my view. It makes for disgruntled, burnt out developers whose ability to deliver quality will suffer.
What seems to cause alarm is making explicit what is needed anyway. Quicker cycle times are achieved by working on smaller pieces of work that get done well. Perhaps customers are surprised about how much work is involved in each small piece. Big stories don’t get completed in the time Product Owners would wish for, but telling that up front and giving them a reality check can upset them. Developers will take time out to avoid burn out anyway, or they might call in sick or spend an afternoon staring at the screen not doing much. This is natural. But admitting it seems more difficult.
