Getting to Done: Balancing Emergence and Delivery

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 releasable software 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 formula.  Teams have to figure out what will work in their situation.

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 deliver of a Done Increment.
3 Challenges Balancing Emergence and Delivery 

1 - New work is being assigned to the Development Team.

The Development Team 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 Development Team.  Remember that the Sprint Goal helps the team stay focused and provides flexibility as work emerges.  If someone is giving the Development Team 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.  This could also mean leveraging management.


• 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 Development Team 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 may 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 all Development Team members participate, 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 coaches the Product Owner on how to best fulfill their role and responsibilities to the team.  The Product Owner is accountable for maximizing the value of the product and the work of the Development Team.  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 Backlog consists of the selected Product Backlog Items and a plan to deliver them.  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 with planning.  Discussing the "how" helps a Development Team 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 ask a team member to kick off the Event by stating 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 what impediments they foresee and need help resolving.


• A Scrum Master can help the team more effectively use the time-box.  If the team usually reaches the end of the time-box before talking about the "how," break this into two time-boxes to help the team focus on both aspects of the Sprint Backlog.  A back and forth between "what" and "how" is normal, but help the team balance this.  If the team ends Sprint Planning well before the time-box 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.  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 whole series on Getting to Done:  

• Encouraging Team Ownership


• Improving Team Collaboration


• Creating Good Sprint Goals


• Tackle Impediments