I was recently present at an attempted Sprint Review Meeting for a team I was coaching. They were struggling to get finished by the time of the meeting, and by the appointed time could not get the functionality ready. The problem was that they had picked eight items, and could not even demonstrate one item, and this was their second sprint! They had earlier done a sprint zero, with many of it’s attendant problems which are described here. Now my overall analysis of how this situation came to pass is at two levels:
1. Poor habits carried over from the waterfall days.
2. Lack of prioritization within the sprint.
Over and above this is the matter of a somewhat diluted DoD (a separate topic in itself) which is bad news being stored for the future. This team was working with a weak DoD, which was seemingly clear to them (For some one who reads tea leaves in his spare time, this is an ominous sign)
In this post I’ll explain the first point. Within the sprint, each story was done strictly in a waterfall manner, including hand-offs. This not withstanding all the training the team and managers were given. Which meant, that the burndown chart, while warning about bad news, actually did not quite manage to reveal the really bad news. That nothing was actually ‘done’ ( this does not mean the team did not do anything). Suddenly towards the end of the sprint 4 user stories were 90% done, and as the old saw goes, the remaining 10% takes the other 90% of time. The other 4 items were in even lower levels of completion. However what was the actual completion is moot. Even more importantly, trying to find out the true completion percentage is missing the point. The team at the time of the sprint review, should try to keep the done/undone as binary as brutally as possible. Try to see it, standing in the PO’s shoes.
So what is to be done? Avoid waterfall. How? Especially given that the team is already facing too much change for comfort (One reason why many teams don’t see successful sprints early on). Assuming they haven’t changed their technical practices yet (very common for teams starting off on Scrum), the first step is to try to break-down user stories to even smaller units of functionality, whose completion should be staggered across the sprint. Another approach that can be simultaneously used is to write acceptance tests as the stories are picked up. This means that the team can test the stories (to some extent) at a very early stage, hence testing early and (hopefully) often. A very good idea.
The above ideas are a reason why teams aiming to succeed have to change their ways of working and learn to breakdown stories and change the approach to testing among other things.
In the next post I’ll explain the other practical step to take (if you haven’t guessed already).