The Sprint That Blew Up

Is it appropriate to blow up a sprint?

The Setting
We were several sprints in with a new team and suddenly the team was faced something new.  Something out of their control caused havoc with the priorities in the Backlog. The work that the Scrum team had committed to for the sprint was no longer needed.  In the Sprint Review the scrum teams voiced that we did not meet our original goals.   The teams and the product owners were hard-voiced about having to “blow up the sprint” and having to “re-plan and re-baseline”.  There was a discomfort level and some confusion within the team as to whether we might have done the right thing. The strongest statement was, “The institution of scrum was disrespected.”

The Cliff Notes Answer
Leadership, stakeholders, coaches, and scrum authors say we all made the right decision and behaved correctly. Changing our sprint backlog in the middle of the sprint made sense because it honored new business objects and the desires of our Product Owners. The scrum play book says it is perfectly fine for teams to break the sprint this way as long as this is the rare exception rather than the norm.
The Detailed Answer
As I am talking with the team I will start this out with saying “GOOD JOB”
and end my conversation in the same way. I start asking QUESTIONS.  
When is it appropriate to Blow up a sprint and re-plan/recommit? 
Are we allowed to do it? Sure.
Always I want to ask questions. The first one is obviously Why? 
Is this a BIG Deal? I think it is.  Firsts often are. 
Were our assumptions on the sprint goals wrong?
What risk did we not think about critically?
What wasn’t communicated?
Does this still make sense?
Were the release themes not vetted from above and below? 
Was everyone on the same page for acceptance criteria for the stories?
What changed our assumptions?
How can we prevent this from happening again?
The Team did A LOT of work! 
We adjusted to the highest priority!  
Will the business expect this as common practice?
How disruptive was this? 
What was the impact? Did we lose 3 days of our sprint?
What did we learn? 
How do we improve?
I write this after the fact because we are empowered to make these decisions.
Don’t regret the decision – learn and adapt.  You have also worked through a fairly large and complicated problem.
You have changed, and will continue to change some of the assumptions we have together, as an organization.
Good Job!
————–Here are some external references from the proverbial Agile Library: 
Succeeding with Agile (Mike Cohn) pg 282 “I usually advise Scrum teams to start taking a firm stance against mid sprint changes. This is not because I am Opposed to redirecting a team or because I want to slavishly obey a Scrum Rule. It is because I want to help those outside the team learn that there is a cost to redirecting the team.  Of course, sometimes redirecting a team mid-sprint is necessary. But, all too often teams are redirected because it’s easy to do and because someone didn’t think ahead. I relax this hard-line stance against change after I see the organization no longer thinks of every new request as an emergency worthy of a mid-sprint change.   Being responsive is what has made us successful, and users expect that of us.
Exploring Scrum: The Fundamentals (Doug Shimp and Dan Rawsthorne) 1rst ed. pg 268 “Cancelling a Sprint. The product owner may cancel a Sprint at any time, usually because the Sprint Goal isn’t going to be met or because the Sprint Goal is no longer what is needed. In either case, the Sprint’s work is evaluated to see what can be kept, and whether or not a replanning is called for.  This is not considered abnormal, but it is simply an agile reaction to something that has happened. It should not be considered a ‘bad thing’ – it is merely a ‘thing’.”
Scrum Product Ownership (Bob Galen) pg 110 “Adjusting the Sprint. … In fact the leader here should be the Scrum Master. He or she is your partner and should guide you in making any necessary adjustments, etc.  However you do play a significant part in the Sprint recovery process, too!
 CONTENT DISCONNECT. The team is struggling to deliver the Sprint contents. Within a few days of the Sprint, you and the Scrum Master realize that an adjustment is necessary. I’ve seen several approaches to this. Classically, Scrum allows for cancelling and re-planning your Sprint.  That works well if you’re a stand-alone team. However, if your team is synchronized with others, then this approach can be awkward in that you’ll need to plan a reduced length Sprint in order to maintain your Synchronization. …  I’ve seen teams significantly recover their progress and often meet the original Sprint Goal. …
 PRIORITY DISCONNECT. … In these cases he (product owner) was more likely to cancel the sprint and then re-plan a new one based on a major shift on the backlog.  However when re-planning we tried to stay open minded about integrating the new work and maintaining some of the original Sprint focus.  Another aspect of this is insufficient look-ahead. I was never convinced that we couldn’t anticipate these changes in some way. Remember, we were on a 2 week sprint model which is fairly nimble.”
Changing direction doesn’t come for free. We are trying to be agile and make adapting lightweight – but a team’s capacity to do so is not infinite.  The time and impact required to pack up what we were focused on, and then re-plan should not be ignored. When we commit to a backlog at the beginning of a sprint, the team is serious about delivering the work and trusts that they have everyone’s support and are allowed to maintain this focus in order to deliver.  Unanticipated work in the middle of a sprint distracts. If a team starts to believe their commitments will be ignored, the erosion of urgency, commitment and trust start to occur. Loss of trust erodes team morale and we’ll eventually find ourselves back to where we started. In quiet silos with being defensive about collaborating.  Our ability to fail early is not a joke.  It is instead a measurement for how quickly can we get to right.   
A message like this should be visible enough to encourage the team we did the right thing.  Some VPs, a few Directors, coaches and half a dozen managers as well as the teams themselves needed to know and think in a manner where there was no ‘us’ vs ‘them’.  There is only “WE”, together.  As in WE will make this better and work together so that it shouldn’t happen again.  As well as, we will be thought-full about the “But if it does…”.   This is what transforms the organization, delivers great software, and as a side-effect, makes some high performing teams.
If you’ve made it this far, thank you for reading through the details.

The Team Physical Task Board

I was once introduced to a new team which was been practicing agile techniques for a while.  As I listened in on their planning, it seemed to blend with other meeting purposes and I came away with an overwhelming sense that everyone was busy.  Especially the louder voices – which would find something for a quieter voice to do here and there.  The team talked about hours.  There were some stories entered into the backlog, and the team talked about a few of them.  Then the team seemed to wind down and proceeded to get back to work.  This is the time for opportunity and to bring a few basics to bear.  To be clear – I get a chance to explain what I see, and what we can improve.

A vision for making a better team.

There is a coach, Bob Galen who talks in terms of pebbles, rocks and boulders…  relative sizing.  pebbles might be equated to tasks – rocks were something bigger such as stories and boulders might be epics.  The proverbial agile mountain would be layered with all three.  The scrum master has to know where their team is on that mountain.  They may even have to act as a Sherpa and lead the team to where they need to be at that moment.  Is this poker planning where we talk about stories, is this the next-sprint planning where we are listing tasks? The scrum master’s gold coin is the focus of the team.  Are we self-examining? resource-balancing? How does this fit into processes? Are we making our commitments?

No room at the inn?

The task board is representative of a teams’ sprint.  There are other information radiators which will scale larger for releases across several sprints – but I’m just focused on the teams’ sprint task board here.   Some teams do not get the opportunity to have a ‘room of their own’s as Virginia Woolf  would advocate.  Instead of complaining and letting it fall into the ether – use this an opportunity to get creative and feel a bit empowered at changing the physical environment.  A team that can walk into a room and move tables without asking permission is far more empowered.  The physical environment acting as a parallel to the thought universe.  There hasn’t been a place yet where we couldn’t make one.  The most creative by far was one that wrapped around two side of a gigantic square column that was ideally situated right in the middle of the team.  They just hadn’t thought of it as usable real estate and took a lemon (sour or negative circumstance) and started making it work for them.  Take painters’ tape and a portion of barren wall.  Use the hallway or corridor – this IS supposed to be about visibility after all.  Try a window, or a rolling board, but try something. Dont get stopped.  Some teams use idea paint, and turn a section of wall into something they can write on with dry erase markers.

3 vertical and one horizontal line.    Stories (Rocks) | To Do (pebbles) | Doing  | Done

The scrum master helps the team spend time together – working and non working. There is much about a board like this that the scrum master takes note of.  Capacity: What is the team’s average velocity at the story-level, and quite possibly how much is being done at one time (task level).  The manner in which it gets done is also telling.  Is the team working highest priority, and swarming as they need to?  Is the team likely to delaminate and each starts their own story?  When did risk surface from the team?  This should be early on and not the day before the end of the sprint. I have my task(s), is it the best thing to be doing right now? Does it contribute to the story?  Does it help the release?  Does someone need help? Large tasks that sit in ‘doing’ all sprint aren’t helpful.  It means we haven’t performed our agile duty and broken it down into something smaller and actionable.  Quick feedback loops.  Are we all on the same page with regards to the end deliverable fairly early into the sprint or are we still thrashing late in the game? Are we improving our interaction? Is the team getting better suggestions from each other and evolving processes and quality of work?

Visibly working and communicating the sprint plan every day in a light touch is important.  Also – Is the plan working? The sprint burn down is a side-effect.  We don’t complete tasks to make the burn down look better – we complete tasks to get the work to done.  The burn down is simply a reminder like a gas gauge – do we seem to have capacity as a team – if not then we need to adjust the plan.  As a scrum master knowing the records for most amount of tasks they’ve ever completed in a day is an achievement worth celebrating.  It gets the team to think as a cohesive group for what they are capable of.  I had an earlier post: Burning Down Not Out

Finding out the the team is experienced and knowledgeable enough to task and tear all the work apart.  Were there any skills or processes or artifacts that would have made the sprint easier?  The scrum master is out to enable the team and remove issues.  This may even take some time to do so.  With enough attention, perseverance and work oysters turn an irritant into a pearl.  The scrum master can even look back on the sprint task board and see how many new tasks were added.   – This is the team learning about what it takes to get everything through the organization and into the customer’s hands.   Always with an emphasis on making the customer delight and re-engage with the experience of how we collaborate and what we deliver.  Some teams may need to call out the preparation for the review as a task for completing a story.  We always want this to be light weight and not overly prepared – more go than show, but some conversation and preparation contribute to a successful review.

We have a plan, and the team has confidence enough that together we can adjust and deliver the work.  What is the team’s confidence in their own plan? Are they engaged and an active part of it or really just waiting around because they know it is doomed to fail.   At the end of the sprint, our plan is pretty much thrown away and the team is left with feedback for how well we problem solved, and worked together to accomplish all of this.  The teams are earning trust by working on high priorities for the business.

Color coding by stickers or by post it’s is often used to convey stage of tasks, if the tasks were added after planning, who might be responsible for a task, or even priorities.  Getting used to Capturing the conversations IN THE MOMENT is an art in and of itself.  It is the lightest weight meeting.  No one leaves with extra cleanup up to do.

Moving a story to Done.

Though tasks are moved by the team – the person doing the work, Teams often like stories moved to done as a ceremony by the product owner.  It conveys they have reviewed and accepted the work.  The product owner should not be surprised by what they see in a review.  The scrum master often acts as a conscious for the team and may probe for definition of done compliance. Especially if this sprint was a new level-up in terms of delivering to the expectations of the organization, role, or the team itself.  “Did we have unit tests completed?”   The team will thoughtfully answer, and we trust them.  Questions should never provoke a team into a defensive posture.  If they do – this is a signal that something else usually requires a bit more investigation and fixing.  Physically touching the work isn’t just an arts an crafts thing – it hits us visually, we feel it, tactile.  This is representing our work that we move with progress from left to right.  It is a visual indicator which radiates information about where the team is at and heading towards.  Within the context of the group – we accept we will make our work visible.  The team talks during the stand-up around the physical board.  Others from outside the team are even invited – but usually don’t speak until after the team is done. You might even judge a successful stand up by the number of break outs that happen AFTERWARDS.   As a team we are also endorsing accountability.  There are some strong proponents for ‘HOLD ACCOUNTABLE’ but I will often say “HELP ACCOUNTABLE”.  Not everyone is good at asking for help, or seeing a possible solution because we are heads down in activity.  Together we rely on each other as a team, and strive to balance in doing the right thing the right way.  No one is perfect every day.  The group together helps, picks up members who might be down, and gets motivated about completing the team goals.  Ever continuously improving to work better and together.

The More Mature Teams

I am looking for everyone in the team to participate.  Problem solving what is needed to get the work done.  This critical thinking is an opportunity to teach and visibly vet what is needed.  It also ends up being a plan for the team.  The team will adjust the plan as it needs to.  This is about driving out risk and unknown.  Teaching the team to be better and better with reliably representing their capability to the organization. Making commitments to the business and customers.    Load balancing the team resources, thinking ahead and envisioning the end game at a couple different levels.  Does this align with our goals for the sprint?> How about our larger goals for the release?  Are there any dependencies we need to address early? Is everyone stepping forward appropriately? Is there some swarming behavior?  Are we focused on the tasks that get the stories to done or are we instead focused on hours which really obscure whether something is simply done.  If you have all that and are a great team, and want to move to electronic forms of tasking, then do so with blessing.  Go faster, improve processes.  Just bring with you the practiced behaviors that you developed together as a team.  Distributed teams rely heavily on this to keep connected. I look for a team to pop – their communication includes each other, their plans for the day are intertwined.  There is a great side effect of having teams like this in every organization.  It is force enough to move mountains.

Burning Down Not Out

The burn down.   If you haven’t used one for your project before, the concept is easy.  Given a lot of something now, how long will it take to get rid of it all.  Work, hours, tasks, budget allocation, release features…  Agile also had the concept of a burn up…  instead of going to zero we simply flip it so that we will accumulate work over time up to a maximum level of something.  Preference was up to the organization, but sometimes both were kept as a way to instantly recognize what level/scale was referred to.  If one was talking about the progress of a team (burn down) or the progress of a release (burn up).  So much of what we do is empirical.  In other words; it is an observed side-effect of our direct efforts. At times this may not be intuitive.  Scrum uses these charts to point our attention to when is done?  It is not an artificial moment in time that is the focus.  It is our software deliverable we really focus on.  The accumulation/dispersion of effort through consistent units of time is represented in a way which helps us characterize if our capacity for this work is realistic.  By knowing our capacity, we are also dedicated in continuously improving the organization’s ability to do work.  We do all of this through great teams.

A Team Burn down  Scale the y axis in hours, tasks, story points and the unit of choice can affect how the team works.  As a scrum master there are some tools which enable the tracking of hours, and tasks and will display both of these for a team simultaneously.  Typically the lines will track each other very similarly though different in scale.  It is a matter of resolution.  350 hours seems to be a finer resolution than 70 tasks, but what if the team enters updates just every evening?  The maturity of the team also comes into play here.  A shu (Shu – new, Ha – intermediate,  Ri – advanced) team, just coming together may find it easier to talk in hours the first few sprints.  As they get better, and need to look up across the sprint.  A bootstrap out of hours and simply into done tasks is usually better. It is a matter of what I will call transaction distraction.  A better term might even be ‘clutter’.  So many things to put a fine point upon that we sometimes lose sight of the middle and end games. Another way to view it is a ‘level up’ as we master some things and begin to practice a higher level of awareness for things of greater scale.   Some teams prefer to retain the hours perspective as a sanity check when planning the next sprint.  It is another lens through which to assess the risk of the work they are forecasting and committing to.  I will use a task burn down and usually focus a ha team on it when we see some risk to the sprint.  Would a ri team even need tasks?  Perhaps the story pointing may be an accurate enough guide for these experienced veterans. A task-level burn down might consider the following:

  • Tasking. Using the task board, establishes a plan. This is the wall or whiteboard around which the team can hold their daily scrum.  I even had a ‘land locked’ team show creativity and wrap theirs around a column in the middle of their pod!  The teams work this plan and adjust the plan daily.  Visible, active, shared problem solving and swarming.  Many coaches like to say Hold Accountable and there is something to this… I prefer to give it a twist though and say Help Accountable.  Not everyone is good at seeing when they are being distracted, stopped by some problem, or simply need help.  Are we getting better as we get accustom to the interaction or even the technology?    Tasks that come anchored with someone’s hour limit – doesn’t prevent, but can erode the swarming behavior we want to see in our teams.  Especially if the estimate is made from a different skill level.  We are not trading hours equally – but if you grab this task we are at a higher level of trust that one of us has the ball and will run with it.
  • Transactional duplication.  There is overhead or a cost to the number of things we track, the tools we use to fill out certain forms.  If instead there was a very simple rule – that would eliminate just some of our effort… we move that much faster.  If we are at a sustainable pace – aren’t we agreeing to average a 40 hour week?  Do we need to track the hours of every task?… probably not.  Also know that most rules have exceptions.  On the whole, however, we are trying to work at a predictable pace where people won’t burn out.  They also need some time to be able improve processes, tools, and even themselves.
  • Characterize.  This is for the team… I would not show a team burn down in a review… maybe an occasional retrospective though. A team can get desensitized by being shown it every day.  Are you looking deeper though?  A scrum master, at times, is sort of  a team historian.  Would you know the most stories or most tasks we ever took on in a sprint and completed?… these small benchmarks can help to identify when the team has improved, and have an excuse to celebrate a broken record.  For instance – I keep track what the MOST TASKS the team ever completed in one day as a team record. It is a RATE – which does depend on the work.  We assume the work will always change.   How about the average number of task closures per day?  It is to identify risk. How well do they task out stories?  The team will help accept and relay confidence or mitigate and problem solve to bring the sprint in successfully.  It is a reality check against how our team performs.  We ask this of ourselves so that we can characterize the engine, the team, and the severity of the situation.  We want to inform the product owner and the program as soon as possible.
  • Focus.  A scrum master directs the focus of the team.  Remember transaction distraction, there is only so many things we can hold in our attention.   Is it really about the hours, getting the tasks to done, getting the story completed, the sprint goal being achieved, or the working software?  At different times, for different circumstances, it could actually be any of these.  What was the price in order to get there in terms of impact?  We use the burn down to be thought’full’.  To alert ourselves to a severity and to address it calmly in the best manner that suggests itself.  The burn down is a side effect of our work, not a focus.   In other words our work is not done just to satisfy the burn down. It is too easily gamed. No one will yank agile badges here, but we use it with the intent to become better problem solvers.  We want to be able to pull our heads up out of activity every so often to assess the situation critically, be creative, and improve a few things while delivering the software.

A Release burn down

The term ‘Characterize’ is a good one to replicate here as well.  It is the way with which we are assessing the organization’s ability to  deliver work. How well can we share this load across all teams for the most important priorities.  What trade-offs do we have to make for our potentially shippable increment.  This helps us tie everything together at a larger level.  Are we even honest with ourselves for what is complete?  What it doesn’t show may be even more important:  things like dependencies and risks. A burn down is just a tool.  It can be like any tool; useful, misused, or dismissed.

Plan your dive. Dive your plan.

I used to be a SCUBA instructor and the title was one of the things we taught our students.  This was before all divers had a computer and, instead, used tables to tell them how long they could stay underwater safely.

Have you ever been diving or snorkeling?  There aren’t many interesting spots, teeming with marine life that are at one depth.  Coral heads, shipwrecks and the occasional sting ray or turtle cause you to adjust your depth and, subsequently, your plan.  So, even the best dive plan requires adjustment.  Today, divers can rely on computers whereas, then, the diver had to rely on their dive buddy and quick thinking.  Good divers were able to handle the changes and appreciated them.  The changes underwater are what makes the sport awesome.

Teams plan.  The stories they accept into the sprint meet the ready criteria.  The team knows what they need to do and they commit.  Then a few days into the sprint something causes them to have to adjust.  Good teams will adjust.  Teams on their way to good will have a harder time.  If they were divers, they would likely go ahead and surface.  You don’t want a team to bail on a sprint.

So, the question is, how do you help the team who is almost ready to bail, stick with it and still feel successful?

This has only happened to me once.  I first asked the team if the problem was one they could control.  It wasn’t in their immediate control, but it wasn’t in the soup either.  So, I asked them to come up with some different ways to solve it (as a team) and to pick one and go after it.  They did.  The cool thing was they adjusted their plan, removed the impediment and still had a successful sprint.  The cooler thing was they realized they were empowered and could, in fact, respond to change and succeed rather than “surface”.