In a previous post describing challenges to creating a Done Increment, I identified too much change during the Sprint as one of those challenges. The Manifesto for Agile Software Development talks about responding to change over following a plan. It also says that the best architectures, requirements, and designs emerge from self-organizing teams.
So how do we respond to change and allow emergence while still delivering something of value that works?
First lets define delivery and emergence. In Scrum, delivery is a usable Increment by the end of a Sprint. Because we are dealing with complex work, we do not know everything about what is needed and how to deliver it before we start working. This is where the concept of emergence comes in.
Emergence implies that all solutions to all problems will become clear as we work, not simply by talking about them. Essentially, we need the ability to learn for experience and respond to what we are learning. This could mean fine-tuning our direction, changing course altogether, or continuing forward as our assumptions are validated.
Balancing emergence and delivery are challenging. There is no perfect formula that will work for every team, every product, every initiative. This is where self-management and empiricism come into play. Teams have to figure out what will work in their situation. And this balance between emergence and delivery will often look different over time, even for the same team, the same product, the same initiative.
So let me provide some guidance on where to start looking if it feels like there is too much change happening, and this is affecting the ability to create a Done Increment. In my experience, there are three common problems that will throw off the balance between delivery and emergence.
1 – New work is being assigned to the Developers.
The Developers should be focused on the Sprint Goal and using the Sprint Backlog to visualize progress towards achieving it. Nobody should be adding work to the Sprint Backlog except the Developers. And Developers should not be pressured or forced to add work that jeopardizes the Sprint Goal. Remember that the Sprint Goal helps the team stay focused and provides flexibility as work emerges. If someone is giving the Developers other work to do, then we have broken focus, and we have undermined team ownership.
Here are a few ideas for handling emerging priorities not in line with the Sprint Goal.
- A Scrum Master can help protect the Scrum Team from outside distractions by teaching them the rules of Scrum, by helping them understand their accountability, by helping them understand what decisions they own. This includes teaching the Product Owner to prioritize new requests in the Product Backlog rather than try to push them into the current Sprint. This includes educating stakeholders about Scrum and which interactions with the Scrum Team are helpful or hurtful. This could also mean leveraging management if there are frequent offenders.
- It can be hard to say no to the “shoulder taps,” but team members can help by holding each other accountable. If someone brings up something they are working on that isn’t on the Sprint Backlog (or they try to add it to the Sprint Backlog), it is the team’s responsibility to question it. This is a hugely supportive thing to do for team members. Everyone struggles to say “no.” Having support from your team when you need to say “not now” is helpful.
- If new work emerges during the Sprint, the Developers and the Product Owner should negotiate. If something is going to come in, it is very likely that something else must come out. Remember that our Sprint Goal should not be changed during the Sprint.
2 – Poor Product Backlog refinement causes the “what” to grow during the Sprint.
Product Backlogs are not meant to be detailed requirements contracts. We expect details to emerge during the Sprint, and there may be a few surprises periodically. However, we sometimes see an overwhelming amount of details emerge during a Sprint. The Sprint Goal becomes unachievable, or the Scrum Team spends so much time analyzing and negotiating that little time is available for actually delivering the Increment. This could be a sign that we are not doing effective Product Backlog refinement.
- Consider having the full Scrum Team participate in Product Backlog refinement. When everyone participates, you get two major benefits. 1) Everyone is part of the discussion of what we are building and why, which reduces misunderstandings later. 2) Everyone can contribute to the slicing and ordering of the Product Backlog items so that they are right-sized and dependencies are reduced.
- The goal of refinement is to get Product Backlog Items to an actionable level of detail. You may choose to make this more formal with a Definition of Ready. I like Roman Pichler’s description of “ready” as clear, feasible, and testable. Some teams will create a visual board that shows the refinement of Product Backlog items to the state of “Ready.”
- A Scrum Master can coach the Product Owner on how to best fulfill her accountability. The Product Owner is accountable for maximizing the value of the product. Refinement is important so that value is understood and achievable. A Product Owner does not have to do all of the refinement activity alone (nor should she). However, if we are seeing symptoms of this problem, a Product Owner may need to get more engaged in refinement activities. Here are some great questions to help coach a Product Owner.
3 – Not discussing the “how” during Sprint Planning.
The Sprint Backlogconsists of the Sprint Goal, the selected Product Backlog items and an actionable plan to deliver the Increment. It is true that this is a loose plan, and the details are expected to emerge during the Sprint. But that is not an excuse to do a poor job of planning. Discussing the “how” helps Developers better understand how much work they can forecast for the Sprint. Discussing the “how” helps identify dependencies, gaps in skill or knowledge, and other impediments. All of these can kill a Sprint if not dealt with early.
- A Scrum Master should reinforce the purpose of Sprint Planning. It is easy for a team to lose sight of the purpose of an event, and sometimes we just need a reminder. I create signs summarizing the purpose of each event and placed them in the team space where the team usually convenes for the event. I ask a team member to kick off the event by reading the purpose and output of the event. Periodically, I ask if the team feels we are making progress towards that purpose. And at the end of the event, I ask if everyone feels that we have achieved the purpose. For Sprint Planning, I ask the Developers to explain how they will work together as a self-managing team to create the Increment and accomplish the Sprint Goal. I ask if there are any impediments they foresee and need help resolving.
- A Scrum Master can help the team more effectively use the timebox. If the team usually reaches the end of the timebox before talking about the “how,” break this into multiple timeboxes to help the team focus on all aspects of the Sprint Backlog. A back and forth between “why,” “what” and “how” is normal, but help the team balance this. If the team ends Sprint Planning well before the timebox without a solid discussion of the “how,” use open questions to draw out this part of the discussion. “This is a large item. How can we break this down into smaller pieces the team can tackle together?” “Do we have everything we need as a team to meet our Definition of Done and achieve the Sprint Goal?” “What dependencies will drive how we deliver on the Sprint Goal?”
- Break the Product Backlog items into tasks or to-dos. Sometimes teams talk about the “how,” but they don’t actually capture what they talk about during Sprint Planning. When we look at the big picture, we may glean new insights about the work. If you are facilitating the event, you may start capturing some of the conversation visually on a white board. You may ask if someone can draw what they are explaining. Offer the team the option to take what they have visually captured and break down the Product Backlog items into tasks on the Scrum Board.
In summary, a Scrum Team must learn to balance emergence and delivery. While there is no cookie-cutter recipe, we can help our teams use the Product Backlog to prioritize new work, have more effective Sprint Planning, and improve Product Backlog refinement.
If you think one of these problems is affecting your team, pick a technique and try it. Let us know how it goes.
Check out the rest of the series on Getting to Done:
