Written by on 1 March 2016

Post-it note refinements

At Coolblue we’re always looking for ways to improve our Scrum meetings. In this post, I’ll describe a new method for backlog refinements that we’re experimenting with.

You might recognize this

Having good and productive refinements can be really hard. Especially with a new team or a challenging project. Before you know it, you’ve spent an hour talking, but hardly any story has been estimated. Half of the team fell asleep during the meeting and the product owner left disappointed.

The hours of just talking are mostly caused by going too much into detail and forgetting about the goals. Endless discussions about what needs to happen in a story can take up a lot of time. These discussions are mostly between the most outspoken team members and the rest of the team’s minds will drift away to better places. Later on in the sprint you might find out that, because half the team wasn’t actively participating in the refinement, the estimations are really off.

Post-it notes to the rescue!

Good refinement sessions are essential for a well maintained backlog. When developers, designers, the scrum master and the product owner collaborate in defining stories, priorities and the MVP, they have a great start for a successful project. But in order to do this, everyone needs to be able to fully participate. Even the less outspoken team members.

As you know, Post-it notes can fix all your problems, including your refinements. They really help. By using them in a refinement session you enable everyone to share their input. The decisions that are being made can be visualised, making the meeting easy to follow.

Post-it refinement

How we changed our refinements

We started experimenting with a new method for backlog refinements. As a scrum master you prepare this meeting by bringing Post-it notes, the biggest sheet of paper you can find, some tape and markers.

Defining the goal.
Place the big sheet of paper somewhere in the room where everyone can see it. The product owner writes down the first goal the team is going to work towards. This can be the first milestone or an epic.

Defining your starting point.
Now take a Post-it note and write down the most basic functionality that is going to add the most value, as a user story. Don’t worry too much about the size of the story yet. Some thin slicing will be done later on. For example: when creating a new camera app, the first story could be about just making a picture.

Collect input from the team.
The whole team writes down what needs to be done for this story on Post-it notes. Don’t discuss them yet. Just collect all the input from the team and stick it on the sheet of paper, next to the story.

Organize input.
The team collaborates in grouping all the duplicate input together. This still leaves a whole bunch of items.

Define the story scope.
For the next step the team moves all the non-critical items from the first story to just beneath the critical ones on the sheet of paper. Moving items out doesn’t mean you won’t work on them. It just means that the first story can exist without that part. Use the team’s definition of done to make sure the story won’t make you cut corners to finish it.

Estimate.
The story is now ready to be estimated. If the estimation shows you that the story is too big, you should split it up and re-estimate. You can do this in a later refinement.

Define follow up stories.
Use the leftover items to create follow-up stories to add value to the first one. You can add more items if needed.

Repeat.
Repeat step 3-7 until the team and the product owner agree on the expectation that the stories defined so far will be enough to enable the end-user(s) to reach their goal. This is the goal the product owner wrote down on top of the sheet in step 1. You can keep the leftover items to put on the backlog as ‘nice to haves’.

Conclusion

Because everything is put on paper, you can start refinements where you left them off the previous session. In addition the whole team will understand why they are working on the stories and what they are trying to achieve. This makes not just the refinement, but also the rest of the project more fun and meaningful.

I’m curious what you think about this method. Would this work for you too? Do you have a different method that works for you? You can leave a comment below.

REPLIES (4)What you say.

  1. 2 years

    Nice! Thanks for sharing part of your process and validating my love of post-it notes.

    How long do your sessions last for estimates like this? For example, is it a meeting per story? Do you handle multiple stories in a longer session?

    • 2 years

      Thanks for your question Alvin. Our refinements take up no langer than one hour. If we need more time, we plan another refinement for the next day. The amount of stories we can handle differs per session. In my experience, if the team ends up talking about one story too long, it might be just too big or complex and needs to be split up first.

  2. 2 years

    Ever tried the Zachman framework to look at the same thing from different perspectives? It really helps all team members (and the business) to understand others and as you said to put things on paper.

    • 2 years

      We haven’t tried the Zachman framework yet. It sounds really interesting though. Definitely worth trying. Thanks!

COMMENTGive your two cents.

*