Blockers to getting a story ready

I like that we have a Definition of Ready for our stories. As a Product Owner it gives me confidence that I’ve done my job properly in analysing and communicating the requirements, and also that the team is ready to hit the ground running when the sprint starts.

Lately, however, it’s been more of a struggle to get stories to a ‘ready’ state ahead of sprint planning. Other things — often external factors — block stories from being ready. And while Development Managers and Scrum Master are often adept at dealing with technical blockers, it’s sometimes left to the Product Owner to manage story blockers.

Story blockers

So what do I mean when I talk about story blockers? Well it’s anything that stops a story from meeting its Definition of Ready. Here are some examples that I’ve encountered recently:

1. Missing or disengaged Product Managers and SMEs — there are some Product Managers that think they can just hand over a list of epics/features (often just one-line descriptions) at the start of the quarter and then disappear, and expect the Product Owners to somehow work out the detail of what is required. I’ve come across a number of different Product Managers that are disengaged and hard to contact, and it is a constant frustration to chase for answers to questions.
2. Dependencies between teams — it’s often the case that we can’t start work on something because we’re waiting for another team to finish building another component upon which we depend. This is normally a symptom of bad program planning, whereby someone thinks it’s a good idea for multiple teams to work on the same thing at the same time — which is a recipe for introducing complexity and dependencies.
3. Technical blockers — we seem to encounter a lot of problems whereby the team don’t have access to the servers, services, applications or environments they need in order to do some work — and as such they are blocked from taking a story into the sprint.
4. Missing architectural direction — sometimes we need to get our architects to make a call on how they think a part of an application should be built. And without this direction, the team may be reluctant to estimate their stories. Of course, they can be encouraged to build uncertainty into their estimates, but if fundamental decisions about architecture are missing the team may have estimation paralysis.

Not everyone is forward thinking

One of skills I look for in a good Product Owner is the ability to easily context-switch between time frames. One minute you might be writing a story for the upcoming sprint, the next you might be researching something for later in the quarter, and the next you might be reviewing or testing a story in the current sprint that one of the developers has just completed.

In order to do the job properly, a Product Owner needs to be able to think about the work in progress as well as plan for the future, to ensure a continuous flowing funnel of work for the team.

Unfortunately not everyone shares this skill. Some people in more technical roles struggle with planning for the future. They’re so busy thinking about the thing they are building now that they put off making decisions about future work. And this lack of forward thinking is often one of the most common reasons for blocking stories.

Unblocking stories

The perfect way to unblock stories is something I’m not entirely sure I have the answer for. But I’m going to be trying a few things over the next few months to see if they help.

I plan to call out dependencies and blockers earlier in the story writing process. It’s too late by the time we get to refinement to be identifying blockers, as we often then don’t have enough time to deal with them before the start of the sprint — even though I try to refine at least a week ahead of time.

And I plan to formalise the capture of these blockers. All too often, when I raise questions in conversations/chats/emails people don’t realise the urgency of an issue, and don’t understand that their inaction in making a decision might be a blocker to someones else. And so if I call out product and tech decisions as story blockers, then at least that raises their profile.

I also plan to have some other backup stories ready. Sometimes, when the team finds that stories are blocked, I’m caught out because I don’t have any other stories that can be swapped in to the next sprint instead. And with the lack of alternate stories to work on, there’s pressure on the team to take in stories that are blocked, as that’s the only work on offer.

Originally published at richardbloomfield.com on August 9, 2018.