Teams are obsessive towards better customer satisfaction and rightly so. High team throughput is one of the important ingredients towards better customer satisfaction. Before we move further, let’s look at what throughput means in business context. According to Wikipedia:
“Throughput can be best described as the rate at which a system generates its products / services per unit of time.“
In order to achieve better throughput, it’s implicit to look inwards, within the team. However some improvement areas may lie in external quarters. Product Ownership is one of those areas. In this blog, we’ll look at some of issues in Product-Ownership which may have massive impact on team’s throughput. We’ll also look at some probable solutions and their relation with “Definition of READY”.
Here are some of the issues related to Product-Ownership, I witnessed while working with some Agile teams:
- In a distributed Agile project, Product Owner sits at onshore and his focus towards project is fragmented as he’s busy in so many other things. The result – he hardly gets any time for backlog grooming and for clearing queries coming from team.
- Team works on half baked stories. The reason being – customer and team have discussion on stories only in planning meeting. That may be too late considering stories may require further elaboration and clarifications which take time.
Some teams decide to resolve those queries during the sprint but that complicates the problem further. The reason being, team continues to follow up during the sprint but may never receive answers in time. That delays the story completion and bloats the cycle time. Customer also feels annoyed as he perceives team bugging him all the time with so many silly questions.
What do you do in these situations? In the first case, it looks like Product Owner is busy in too many things. Team management may initiate discussions with customer management but many a times, nothing changes because of existing HR constraints at customer side.
Now the simplest choice is to keep sulking and do nothing about it. But as a result, team suffers and customer suffers with the outcome.
Believe it or not, it’s the story of many projects. Is there any other alternative?
How about helping out the customer to come out of the mess? One quick solution is to let Scrum Master help and coach the Product Owner in backlog grooming. This works pretty well for a small Scrum team. However for bigger teams, Product Owner may require dedicated help.
Let’s look at second problem of half-baked stories. What to do in that situation?
The idea of “Definition of Ready” tries to solve that.
Simply put, any user-story coming inside Sprint backlog has to be READY and any user-story moving out of Sprint must be DONE.
In order to come up with “READY to play” stories, team conducts regular backlog grooming sessions with Product Owner.
In a backlog grooming session, Product Owner explains user-stories one by one. Team ask questions to be clear on the user-story and thrashes out all grey areas during discussion.
As user-story becomes clear and team doesn’t have any unanswered question or blocker remaining, the story is considered READY. Team then estimates the user-story in story points. This process continues during entire duration of the session for other stories as well. For some stories, Product Owner takes a note of unanswered questions and park those stories for further analysis.
Apart from removing blockers, the idea of “Definition of Ready” is also to come up with a common understanding between team and Product Owner on READY user-stories.
In the teams I worked with, the frequency of backlog grooming exercise used to be once in a week for 2 weeks sprint. However, it’s up to the team to come up with right frequency, which works for them.
The simplistic “Definition of Ready” looks something like this.
And a more detailed version looks something like this:
In order to have better planning and visibility, Product Owner and Scrum Master can share a Kanban board containing probable backlog of next 3 sprints. Here’s an example of Ready Kanban board:
If you look at the picture above, user-stories under Iteration+1 column are not implicit candidates for next Sprint planning. Only stories under “Ready to Play” column are the potential candidates for the Sprint planning.
In general, user-stories becomes clearer as they move from left to right on the Kanban board. For instance, when a story is placed in Iteration+3 column, it may have just high-level details but as it move further towards Iteration+2 or Iteration+1, more details get added and story becomes clearer.
Working towards “Readiness of the stories” helps the Product Owner in a tremendous way in organizing herself better. At the same time, it helps the team even more as team-members no longer wait endlessly for blockers to get resolved during Sprint. As blockers in a pipeline of continuous flow get resolved early, sprint throughput increases and hence overall team outcome.