Developer code of conduct for Scrum Refinement ceremonies (Scrum series 1)

Refinement sessions. Some people like them and few enjoy them. Over the years, I’ve worked across multiple companies who embrace Agile, particularly Scrum. I’ve started my career with Agile and so far, I’ve worked in organisations who are either mature Agile organisations or those who are transforming themselves into being Agile so I like to think that I have a pretty good grip on what an organisation’s Agile ideals should be. However, ideal things don’t happen in practice – and that’s a good thing because I don’t think that all organisations can wear one single Agile hat.

Different places have different ideas about what a refinement session should be about. Some think that its an opportunity to connect with the product owner at technical level while others think that it is an opportunity to itemize stories by capturing more detail in them. Then there are also some outliers who think that refinement should be about the dev team and how they feel about the stories that are in the backlog.

I think that all of the above views are correct – up to an extent.

Refinement sessions provide an opportunity to connect with the product owner. While, as an agile team, you should be regularly talking to your product owner, constantly getting feedback on your work anyway, refinement sessions allow the whole team to come together to review upcoming work in the backlog and at the same time, negotiate the required amount of work with the product owner. However, this shouldn’t become a tug of war but rather an open dialogue where ideas are allowed to flow freely. This is an opportunity for the development team to connect with the product owner at ‘why’ and ‘what’ level so that they can find and apply meaning to their work.

Refinement sessions are about itemizing stories by packing as much detail in them as possible. This is quite popular. I’ve seen people getting into low level details during refinement, talking about ‘how’ instead of just ‘what’ and ‘why’. If you have highly technical people in your team, who know loads of stuff and are packed with experience, or just people who are highly motivated and just can’t wait to start working, then either you’re already having this mindset or will be facing it soon. Its not a sin to go into low level detail but it is when people go into it for too long. Remember, “I want a API orchestration layer” or “I want my posts to be fetched from a JSON REST compatible API” said no customer ever. Refinement sessions are about capturing enough detail from the user’s point of view for the development team to get started.

Refinement sessions are about dev team and how they feel about the current state of the backlog. Very few people see it from this point of view as most forget that it is a two way conversation between product owner and the development team. Product owners don’t own the team. They own the backlog and the work that is in it. Development team has every right to negotiate items that are on there if they feel that it is the right thing to do for the team. Another development team might not feel the same way but that’s not the point as they are not the ones working on it. In some cases, the backlog is not ready to be refined as items that are on it severely lack purpose, let alone the details. In this case, the product owner should go back to the drawing board and get the information that is required to give a story its meaning. The story can be skipped or the session can be ended if no story is fit enough for refinement.

In addition to complying with all the “rules”, I think that the teams should also meta-refine refinement sessions. If they are becoming a chore find out why. Liven it up a bit. Change something, gamify, let someone else drive the sessions or try out new things in general. You’ll eventually find a sweet spot.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.