Tag: refinement

Too Many Options

Teams collaborate to create high-quality products, and in order to collaborate they need many discussions… but how much discussion is too much?

Why do teams need to have discussions at all? Wouldn’t it be quicker if someone created a series of tasks and then the team just implement them? Well, it may be quicker to release something if everyone just did as they were told, but there are so many problems with this approach that I don’t have time to list them all! Some of the biggest issues are that it’s a single person’s understanding of the problem and the rest of the team probably don’t understand what they’re doing or why, which leads to a sub-optimal solution which the team can’t support without that one person’s involvement… but the “hero” of that project has no doubt been moved on to something new, set to repeat the “success” of that rapid release.

Instead of relying on a single person (who I’m trying to refrain from calling a single point of failure) Agile teams collaborate on all aspects of their work, sharing their knowledge. User stories focus on the Who, What and Why, leaving the team to work out How. The Product Owner sets the scene, explaining the business aspects; the development team should seek to understand their customer, how this story will impact them and what benefits it is expected to deliver. This discussion may take a while, but it’s usually the next step that takes the most time: deciding how to produce that deliverable.

Before starting a sprint, the dev team need to have a reasonable idea of what they will deliver. They need to have enough understanding of their approach that they can have discussions with the Product Owner about the size and scope of the work, i.e. the Negotiable part of INVEST. Teams can go overboard and spend too much time upfront; there will always be surprises during a sprint, so it’s better to limit the pre-work and put that effort into the sprint work. But if teams go too far the other way and do no preparation, then they miss the opportunity to discuss how much is “just enough” to meet the customers’ needs.

What happens if the team cannot agree on how to approach a story? The team could keep discussing their options ad infinitum, often called analysis paralysis, but at some point the team have to recognise that they are not converging so continuing to talk will not help. They could invite others to join the discussion, but that can lead to problems around impartiality; it also doesn’t help the team learn how to react the next time they reach an impasse. One helpful step could be for the team to conduct a spike, building a small proof of concept so they could compare a key difference. Perhaps a few spikes are needed in order to extract the best pieces of each approach – it’s rarely as simple as A or B, and more often is a hybrid.

One last thought: don’t just discuss ideas – draw them! Not everyone can draw (I’m terrible!) but a tool like mural.co makes it easy to use their built-in images or import graphics found online, so there’s no excuse to skip this important step. It’s too easy for team members to think they all agree on the approach, but making it visible will help bring any misunderstandings to light.

Keep your backlog brief

Your product backlog is probably too long. A quick way to tell is to look at the items at the bottom of your backlog and consider two questions: do you know their origin (who requested them and why), and assuming the team works through the backlog and eventually completes those items will they still be valuable? There’s a good chance that the answer to at least one of those questions is no, and that’s an indication that your backlog needs attention.

I often refer to Henrik Kniberg’s “Agile Product Ownership in a Nutshell” video because he covers so many key points, especially the need for the PO to say “no” so that the backlog remains relevant and realistic. The backlog should not be a place where ideas go to die! When a stakeholder says “I really need feature X” they’re probably hoping to see that feature delivered in a few weeks or maybe a couple of months – if the PO has to tell them it’s going to be 6 months or more, then why are we doing agile?

Aside from the benefit of setting realistic expectations with your stakeholders, keeping your backlog brief makes it easier to see what’s there. (This is especially useful if you use a tool like Jira which randomly adds new items to the top or bottom of the backlog!) There is also less effort invested in creating those backlog items, which means there’s probably less resistance to throwing them away when the direction changes. The same can be true for the sprint backlog. If your sprint backlog is long and unwieldy then the root cause may be that the team are breaking things down into overly detailed tasks, over committing in sprint planning, or have too much capacity (e.g. sprint is too long, or too many people in the team).

One concern I’ve heard about having a short product backlog is that it doesn’t give the team a sense of long-term stability, e.g. the team may be disbanded (or even laid off) once everything in the backlog is done. However, I think if the team are concerned about their future then there are bigger issues to address than the backlog, and artificially adding items to try to calm the team is disingenuous, contrary to the openness and honesty we promote.

The Scrum Guide describes refinement as “the act of breaking down and further defining Product Backlog items into smaller more precise items”, which is usually how product backlog items are made ready for sprint planning. I think what’s missing is the attention that a PO gives the product backlog, maybe in conjunction with the stakeholders, to prune the backlog in order to keep it focused on the upcoming needs – probably the largest part of the PO role is the communication with the stakeholders, and I think Henrik’s video gives a great overview of how much happens often without the team’s knowledge.