Feature Refinement Process

When you come to the company that is on their way of Agile Transformation, one of the things that they will look at is how to prepare future work to the state that it can be planned by teams. Often this process might be called as Product Backlog Refinement, Grooming, Feature Refinement Process, etc.

In this article I outline 5 important artefacts that should be in place in order to have a good feature refinement culture in the company.

1. Prioritized Backlog

One of the 7 wastes of Lean Manufacturing is Overproduction. This type of waste doesn’t belong only to the actual production or implementation. It relates to other stages of the value creation as well, including refinement. And Overproduction is a mother of other 6 wastes, so we should pay a great attention to it.

Imagine a team that have done a great analysis of a feature. Prepared it to the state that it is clear what the business value should be delivered, together with Product Owner refined acceptance criteria, identified dependencies to other teams, outlined direction for possible solution, etc. Team worked together and proud of their work, team is looking forward to starting this feature. And then they realized, that this feature is not prioritized and instead they should look at another one.

What has happened is over-refinement or refinement of the thing that noone currently needs. As a result, another important feature wasn’t refined, team wasted their time instead of spending it on value creation, team’s morale went down, and team isn’t sure if “this refinement thing” is a good one.

So Prioritized Backlog for the coming planning period is what you need before you are going to start feature refinement.

2. Time for refinement

It is naive to think that team will do refinement as a side job, will manage to find some time in addition to working on delivery of what is in progress, in addition to bug fixing and other priorities.

Time for refinement should be allocated. There are basically two ways on how to do this:

• Team plans time for refinement during Sprint Planning meeting.
• Team has some % of their capacity always allocated for refinement.

In the first case, there is more flexibility. Depending on the size and importance of the refinement task, team together with Product Owner may vary the team’s involvement into refinement in the current Sprint.

In the second case, team usually have around 10–20% (heavily depends on the context) of their capacity dedicated to refinement of future work.

3. Operating rhythm

Ok, great, we have Prioritized Backlog, so we know what to refine next, we have dedicated time for refinement, what is next?

Team should agree on when and how they do refinement.

Some questions to consider:

• How often do we meet and talk about refinement? E.g. once in a week or every second week?
• All team refines together? Or some team members and then they share?
• Are we doing refinement on these meetings or in between?
• To whom we should share refinement outcome? To Product Owner, other teams, other stakeholders?
• When do we share refinement outcome? On Sprint Review meeting?

I can share one example from my experience, where:

• team had 1 hour refinement meeting every week;
• refinement usually was done by few team members, securing the rotation, and also knowledge sharing;
• refinement happened in between the meetings and on the meeting there was an alignment and discussion;
• refinement outcome was shared to Product Owner and to all teams that worked in the product area;
• refinement outcome was shared on separate weekly meeting.

This concrete example worked pretty well for the team, and this was result of many experiments and iterations to improve the refinement process.

We should understand that there are no best practices to these questions, and answers heavily depends on the context where team is working. But these questions are definitely the ones that team should consider.

4. Definition of Ready

Ok, great, looks like we are ready to start refinement, anything missing?

Yes, we need to agree when to stop refinement. Overproduction waste may come not only from refining the wrong thing, but also from over-analysis.

Team together with Product Owner should agree on so called Definition of Ready. This artefact will indicate set of agreements that tells you what should be considered in refinement. So team understands when to stop and when they feel feature is good to go for planning.

Remember that Definition of Ready is a living artefact and it should be revised as product, market and team changes over time.

5. Visualisation

One of the pillars of Agile is transparency. Transparency enables inspection and adaptation, which in turn enables continuous improvement. Transparency eliminates need for status reporting. Transparency helps to align and have common understanding.

And transparency can bring all these benefits to feature refinement process as well. Visualise the current state of your features. There might be different ways of how to accomplish this, but usually a Portfolio Kanban board is a good start.

Below is the example of a simple Portfolio Kanban, which gives great transparency on what is currently in refinement, what is already in the Backlog and ready to be planned, what team is currently working on, etc.

Your visualisation should be in the tool where team is working (e.g. Jira, VersionOne, etc.), so there is automatic update of feature statuses. This will give confidence in data accuracy and in using the board.

Having these 5 atributes in order will give you a very good foundation for your feature refinement process. And then, in spirit of continuous improvement, there is no limit on how to make it better.