Tamagotchi

Maybe you have heard of the term 'Grooming'. It was the term I used for refining backlog user stories, but since I heard that grooming was associated with making contact with under-aged children, I prefer to use Refinement.

Nursing

Now the stage is set to talk about refinement and my little experiment with it.
If you have trouble handling user stories in your sprint and underestimate or overestimate a lot, you might want to use my approach for having control over it. If I was asked to come up with a name for this approach I called it: Nursing. In this blog I will walk you through the concept of nursing and tell you step by step what we do from-out the 'Trenches' of my scrum team.
I immediately thought about the tamagotchi toy. You have to feed it and give it attention, because it dies if you don't.

First day of the sprint

This is where it all starts to happen. We have just created a brand new sprint and we are about to start working on it. From the planning, where the current sprint is just formed and agreed, we look beyond the sprint and try to figure out what the upcoming sprint may look like. In practice, we create an other sprint on the shelve and fill it with the top of the backlog, of-course agreed with the product owner. This is the beginning of a two weeks mission to clarify the hazy and misty image we got of the next shelved sprint.

Three stages to become familiar with each user story

There is an order to get familiar with an user story the right way. Developers usually have the urge to immediately start with implementing and finding a solution for the feature. In short, all disciplines kind of lean towards another direction, which is in their interest area. In other words: we create our own image of the feature and keep it for ourselves. I'm a little bit exaggerating of course, but this is what mainly happens.
You can divide 'knowing the user stories' into three stages. (At least, that's what I came up)

Stage 1: Use cases

In stage 1, the team tries to find out what the user story is about. And the most important thing is, why does the user wants this feature? Try to get to the questions behind the questions. Questions might be: 

• Most of the time, the feature is a solution. But is the feature THE solution the customer really needs? 
• You might also consider if you are trying to create some kind of workaround? 
• Which customer needs this feature and shouldn't there be a permanent solution for this 'problem'? 

You can ask all kinds of questions here. But be alert that you stick to the use cases and not trying to create scenarios or solutions at this stage! (Maybe you can break up the feature a little bit into several user stories! Whoohoo!) (The usual format of a use case (user story) is: As a ... (persona), I want to ..., In order to ....)

Stage 2: Scenarios

So we know what the customer wants and why the customer wants it. We can now talk about scenarios. What kind of personas are relevant for the scenarios and what kind of variations or deviations can you come up with? 

I have to point out that this is not the time to get all scenarios thoroughly correct at this moment. Again, it's only to make everyone in the team aware of the situation and get a good feeling about: what is about to happen during the next sprint. You must be all on the same page. (The usual format for a scenario is: Given ..., When ..., Then ...)

Stage 3: Consequences and Risks

This is the stage where we find out what the current status of the code is and what kind of tests there are. We have to know the current situation of the implementation before we are going to work on it. The testers need to know which tests there are and need to find out what more of them need to be made. The developers trying to find out technical debt, dive into the code and see what they are up against.

Estimation time!

Now you nursed your backlog well enough, it's time to estimate. Everyone now knows what to expect from the user stories, so estimation should go smoothly.

Recommendations

• Try to not find a solution during the refinements
• try to get as familiar with the user stories as you need to, to end up with a good feeling about them and therefore create trust.
• If you do not nurse the next sprint well enough, it might become infected and therefore less controllable.
• What you can do with less people than the whole team, you might want to consider to actually do with less people. Like one tester, a developer and a product owner. For example: create scenarios. But you have to present them to the team at the next refinement.
• Before the end of a refinement, you can make tasks to be done, before the next refinement begins, like investigation tasks. Find out what you want to do together, or you want to do in sub teams.

One more thing

You maybe wondering where the solution comes in. I know for sure that everyone in the team has thought about: how are we going to implement it? When you start a user story, you can have a brainstorm about that. 

The way it looks like in the user interface is absolutely not the most important thing! You need to find out during the implementation. The most important thing is that you have implemented the feature in the most simple way. Tweaking comes later. Feedback will give you new ideas.