Last July the main theme of Scrum Day Europe was the celebration of 20 years of Scrum. We took a look at worldwide Scrum usage and agile adoption, and what to focus on in, what we called, the next iteration. We see that an agile way of working is being more and more adopted, but we also see many organizations stepping in pitfalls and we even see some dysfunctions. One of those dysfunctions is the inability of Development teams to deliver a releasable Product Increment every Sprint.

Delivering products

I come across many different Scrum Teams and what I see in general, is a lack of focus and an organizational level of ambition that exceeds the total delivery capacity of the Development teams. If I then take a look at their Product Backlogs it becomes strikingly clear, time and time again, that the Product Owner (PO) just copied the old project plans to her Product Backlog. She is focusing on making deadlines instead of delivering products, despite the name of her role and the artifact where we are looking at (Product Backlog).

The change from doing projects and making deadlines to delivering great products and services has not yet started. In my opinion, we can kickstart this change by doing Product Backlog Refinement properly. To do refinement properly, I am proposing a toolbox in this blogpost.

First I would like to address Product Owners: if your Product Backlog mainly contains solutions for the Development team to implement, please throw your Product Backlog out of the window and start over. What we want is problems for the Development team to solve and I will explain how to get there.

The Balancing Act

There is a great balancing act needed. You may be familiar with the term Velocity. And to me, there are multiple Velocities. Lets take a look at the agile supply chain for product delivery.

Kniberg supply chain

This picture is taken from Henrik Kniberg’s excellent movie Product Ownership in a Nutshell. I added two velocities in this picture. On the left hand side we see VR, the speed of refinement. This is the speed at which the Scrum Team is able to turn business needs into ready Product Backlog Items (PBIs) for the Development Team to pick up in Sprint Planning.

On the right hand side we see VD , the speed at which the Development Team is able to pick up PBIs from the Product Backlog and turn them into potentially releasable product increments. The two velocities need to be in balance.

Proposal for a Refinement toolbox

So we now need a system in which we (1) have a Refinement velocity that is about equal to the velocity of the Development team, and (2) we need to feed the Development team with problems to solve so that they can turn them into implemented solutions.

The toolbox that I propose is a series of refinement workshops, coupled with a refinement calendar that the Scrum team can adjust dependent on their needs.

A business need is identified

A business need is identified. This can happen in all kinds of ways like checking customer feedback, looking at competitors, identifying market opportunities, just some employee passing by with a brilliant idea, etc.

To make sure the Product Backlog is not cluttered with all kinds of wishes, the PO first checks every business problem and stakeholder wish with her product vision. If it does not conform to this product vision, the PO can simply say ‘no’ to the question of putting the item on her backlog, and explain why.

Idea checking

If the business need complies with her product vision, the item is put on the Product Backlog. It is still a pretty vague business need, the solution is not yet known, let alone the size and the value of the solution.

The toolbox

The toolbox I envision contains the following workshop themes and can be performed by the following workshop formats:

Theme Visioning Big Picture MVP User Stories
What is done The vision of the idea is created The bigger picture of the required functionality of the solution(s) is created The building block(s) of the solution(s) is created

Functions and features that we want in the product are defined

A decision is made on what to build first (what does the MVP look like)

User Stories are written

Acceptance criteria are written for each User Story

How can this be done Vision board exercise

Business Model Canvas exercise

Lean Canvas exercise

Writing customer journeys

Impact Mapping

Story Mapping

MVP creation

Apply principles of CCC and INVEST in writing User Stories

The Development team writes User Stories

Who should attend this workshop PO

Stakeholders

PO

Stakeholders

Development team

PO

Development team

Stakeholders if necessary

Development team

Stakeholders

PO if necessary

When is this workshop successful There is a rough value estimation for the business need

Value estimation is done making use of e.g. T-shirt sizing or is in the order of 100s when applying Story Points

Value estimation is in the 100s for the different solutions

There is a rough business case for each solution

There is a first effort estimation in the 100s

The Minimal Viable Product (MVP) is known

Effort estimation is in the order of 20 or smaller

There are multiple ready User Stories

Acceptance criteria of User Stories are known

Effort estimation is in the order of half the Development team’s delivery velocity

Refinement frequency

So we now have a toolbox consisting of four workshops that have multiple different formats. To construct your refinement process, all you have to do now is schedule refinement meetings, choose what kind of workshop you will have (Visioning, Big Picture, MVP, or User Stories), and what format you are going to use (e.g. Vision Board exercise). By adjusting the frequency of those meetings you can adjust the VR.

With respect to refinement, a slow pace may be required when the Development team has created the product up to a point that all truly valuable features are already created and there is not yet a new business need. The calendar for this team, working in a 1-week Sprint, may look like the following:

Schedule 1

It might be the case that in this frequency, the whole refinement process is done in about four weeks. When suddenly a new business need pops up, you should increase the frequency and/or adjust the duration of the refinement meetings. You may very well end up with a schedule that will enable you to do the whole refinement process every week:

Schedule 2

You can now plot the workshops as follows (just an example):

Schedule 3

The PO Kanban board

Oftentimes, the PO gets the question from her stakeholders where their brilliant ideas are in respect to the product development pipeline. I propose taking the phases of the toolbox, and putting them in that order. This is just an example to make the flow visible. The full Kanban board would then look like:

PO Kanbanboard 1

PO Kanbanboard 2

Proposal

I now proposed (1) a toolbox with a chronological order to pull business ideas into the Development team, (2) a way to balance delivery velocity with refinement velocity making use of a flexible refinement slot calendar, and (3) a PO kanban board that she can use to continuously inform her stakeholders about the refinement process.

Please let me know what you think, so we can refine this further! 🙂

Advertisement

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s