“Ready? Steady! Go!” That phrase echoes from my youth. I used to twitch waiting for the starter to shout that phrase at the beginning of the 800m races I ran, representing my school. It was also the title of a ground-breaking pop music show which caused me to fall in love with Dusty Springfield, Sandy Shaw, and every other female singer who appeared (I was a very impressionable teenager). It resonates today for me in Scrum.
When Development teams pull Product Backlog Items (PBIs), or user stories, from the Product Backlog into a Sprint they need to be ready to hit the ground running immediately after the Sprint Planning meeting. For that to happen, the PBIs must be in a state that allows them to do that. One of the responsibilities of the Product Owner, stated in the Scrum Guides, is “Ensuring the Development Team understands items in the Product Backlog to the level needed”. Now that understanding itself is dynamic. What the developers need to know about items far off on the build horizon is different from what they need to understand about the ones at the top of the Product Backlog. The far-off ones are likely to be pretty vague and coarse-grained. That’s OK because the details of any requirement have a huge potential to change before any work gets done on them. If the team has a general understanding of the item, and understands why it is lower down in the order of importance – in other words has a broad understanding of its relationship to other PBIs – that’s normally good enough.
What happens, though, if any given item is still vague, and the team has only a woolly understanding of what is required in Sprint Planning? I recently had an extreme example of the problem. A young, rapidly growing organization had decided to try using Scrum to fix some of the problems caused by its growth pains. Demand for new features in its products had clearly outstripped its capacity to supply. The CEO was skeptical, but agreed to let the organization try out Agile development. However, after about three months of development, the productivity of a key team had dropped by something like 50%. It seemed that Scrum had made things worse! Having helped them get into Scrum in the first place, I decided to investigate…
It turned out that the Development team, which was running two-week long Sprints, was spending four days on average after each Sprint planning meeting trying to work out what the stories they had committed to actually meant. This left only six of their nine working days (they spent approximately one day in total in Scrum meetings) for development. All the refinement of the items – the adding of the detail to the items to get them ready – was being done AFTER they had decided what to pull in from the top of the Backlog. And – guess what? – their forecasts were off by a mile too. Their estimates of the effort needed were being made without enough information on which to base them.
Scrum wasn’t failing the organization. The organization was failing to implement Scrum. The Development team, by accepting unready items, ended up substituting for the Product Owner and were effectively being distracted from their own prime responsibility which was to create a potentially shippable increment. When I pointed this out, there were some objections. “How can we develop anything, if we don’t do the work to understand the stories?” said one developer, defensively. My answer was that she was absolutely right – well, almost. The Development team cannot develop anything unless they have an understanding of what is required. So what should the Development team do? They should “Hit the Beach”. Since this team worked miles from the coast I paraphrased, “Go to the park”. There was a stunned silence. Followed by the Product Owner saying, “That’s rubbish. The company cannot afford to have developers on salary, but doing no development”. And that’s when the penny dropped, as they say.
In a Sprint, the main responsibility of the Development Team is to get the items or stories they select from the Backlog from ‘ready’ to ‘done’. The Product Owner is responsible for getting them to ‘ready’ in the first place. Now, let’s be clear. The Product Owner doesn’t have to do all of that work herself. She may – if the Scrum team as a whole agrees – delegate some or even all of it to the Development team or, perhaps, to a completely separate team devoted to supporting the Product Owner. Such teams are often referred to as Product Owner teams. Whoever actually does the grunt work, it is still the Product Owner who is responsible for it, and for making sure it happens BEFORE the relevant Sprint Planning meeting.
A good way to focus the discussion is for the Development team to draw up a “definition of ready”. This might be a checklist of the things the team needs to know before it can start development. It should also include a size limit (in story points, say) for any PBI that is a candidate for being pulled into the Sprint. The team will still need to split things up further in order to create the Sprint Backlog. But, if it is given PBIs that won’t fit comfortably into a Sprint in the first place, then an extra and unnecessary burden has been placed on it.
If a definition of ready is created, it is important that it is used as a guideline, and as a focus for discussion between the developers and the Product Owner.
Used more formally, it can quickly become a substitute for genuine collaboration and can easily turn into a “phase gate” sign-off document. This is a risk that must be guarded against. What requirements documentation, for example, the Development team needs can vary widely from PBI to PBI. Sometimes it needs to be fairly detailed, while in other cases the team will have an instinctive feel for what is required and can deal with less. The aim is to smooth the way for the developers to be maximally productive from the first day of the Sprint. The particular team I mentioned above is trying this approach now. As Dusty once sang, here’s “Wishin’ and Hopin’”