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.

Scaling By Analogy: Using Story Points

As the story goes… A city once kept a knotted piece of rope so intricately entangled that it was impossible to untie.  For all who tried.  Alexander the Great walks into town, and when he tries, he can’t even find the ends of the rope…so he uses his sword to cut the knot in half.  A solution from the battlefield brought into rope work.  The Gordian knot is now a problem that has been solved, although in a very nontraditional, unexpected manner. We used to get hung up on hours- how long something took to complete.  We were usually wrong.  The human species needed clocks because temporal management may not be entirely instinctive to us.  We changed the focus to get up out of hours and instead focus on task completion.  Doing the right thing and in alignment with the business.  Having an urgency for a time box that is the same cadence, always helps with our urgency, commitment and focus.

Analogy.  It is a way of thinking which transfers meaning or insight from one topic into a different realm, subject or topic.  From analogy we problem-solve, make decisions, explain, communicate, compare, create similes and say this thing is like some other thing.  It is often very useful when the work we do constantly changes – and yet we still need to compare when this work is BIGGER or smaller than some other type of work we did.   Humans long ago knew to size up danger from a big bear immediately and differently than from seeing a little rabbit.  Same with problem solving.  Stay with me… this all ties together eventually.

Scrum uses story points to estimate work.  That’s right.  Something that sounds made up and imaginary to be told to young children at bedtime.  This method also works really well for estimating work. Also, just like anything else – at times can be misused and misunderstood. Teams may have a series of cards, or use cell phones to display a number that is somewhere close to the Fibonacci series.  0,1,2,3,5,8,13,21,34,55 or maybe 0,1,3,5,8,13,20,40,100.  We talk about the work or ‘story’ that needs to be completed, and then we vote a sizing.  If we disagree then we talk about why we voted as we did, what we may have missed.  We typically capture this conversation for future reference.  It is one level at which we will assess the work before we actually commit to doing it, as a team, later.

I wanted to point out some common bumps in the road that teams can have.  Irregardless if they are just starting along their agile journey, or if they have been estimating stories for years.

Troubles with Story Points – what to avoid:

Anchoring. Don’t  let one person consistently shout out their determination before we all vote at the same time. – This typically anchors the rest of the group, absolves them from any critical thinking or questions and does not help teach what may be involved to others… Don’t anchor the estimate – just speak to what is involved, and effort.

Consensus.  Do we all need to agree and stay till the wee hours of the night or is a simple majority OK? Does our majority make someone consistently irrelevant? Does this team member still not seem to get it? I want to emphasize the team working together quickly and well.  Moving forward.  If you want to see and compare some other teams that either charge in and problem solve or seem to stop and thrash when presented with a problem or challenge – I usually like showing teams these videos.  These are teams going through an LRC – Leadership Reaction Course.  I often stop along the way to ask what they see is happening. LRC1 (How do the 3 teams compare?, Is one team placing emphasis on blame or where they succeeded?) and LRC2 (Did they change their process along the way? What did the team forget?)

Bidding.. This is not lowest bidder. – If Madam X does it then it’s a 21, if Mr. Z does it, then it’s a 55. Discontinue the delamination of your team. Discourage the work of the roles ever separating, not mixing, learning, improving until we are no longer a team.  A team leverage resources, trusts and exhibits a swarming behavior that everyone will pitch in to help get the work done.

Re-estimate the past.  Don’t.  Just keep moving forward.  Emphasize to the team that I want you better on the estimates were are making from this point forward.  There are also exceptions to almost every rule.  The only re-estimation I might do, is if this is a special reference story that your team can use to compare the size of OTHER work that it will estimate in the future. Perhaps this work is significant and sticks out in tribal memory of the team.   This story was really a 20 – and since it is sooo vivid in the team’s consciousness, it is now a standard for the next quarter to compare the SIZE and effort of different types of work to this particularly memorable one.

 – Making in-between values to be more precise… Don’t.  Once we start using 3.5 and 26, then we are right back to arguing hours.  The results are just as successful.  Be comforted in the thought that statistical distribution of all a team’s size ‘8’ stories – some were bigger, some were smaller but most will be pretty close.  In fact i might have had an 8 that turned out to overlap a  smaller 13. – Again don’t re-estimate.  Just become better and keep moving forward.  Trust that there is a variability to these mutable, intangible, team specific story points.

Other Factors

 –The team is constantly changing.  A team that is allowed to stabilize, go through storming, norming and performing, will have an easier time and more consistent estimates.

The team is judged by velocity only.  Don’t.  Take a look at the work they are doing even without the estimates.  Is it challenging, is the team growing to take on different types of work? How predictable are they for their commitments.  How robust and reliable is the solution they create?

The team just has 1 big story.  Really? all the time? This might point to a team’s lack of ability to critically break work down, narrow scope, or improve processes.  1,2,3,5, are fairly close, as they should be.  At a smaller scale we should be more accurate.   The Scrum master acts as a historian for the team and should be able to answer – What was the most amount of stories we estimated in an hour? What was the biggest story we ever completed? What was the most (number irregardless of size) stories we ever completed?  What is our average number of story points?  These aren’t to prevent a team so much as to ask the question, and have the team ponder, think differently for a moment and either confirm or change their answer on whether they feel this work can be completed.

Recycling.  Normally a good thing right?  This has to do more with the story that with the sizing.  We do iterate to improve things. Except when it is the SAME old story again  and again. Even kids pick up on this one. – I have known some teams to hide in a particular story and do the SAME work over and over and over.  They never finished a good deliverable.  Not a good way to represent value.

No Guess. No Conversation. Sometimes this is a matter that the stories are a bit too fuzzy.  Perhaps some time has to be set aside to make these a bit more ‘mature’, better vetted, or formed if this is not happening naturally in the moment.  Don’t allow team members to consistently abstain either.  There is nothing to be wrong about – this is a lean in moment to help problem solve and see from everyone what might be involved in doing this work.

Cards – Have some made for your team!  There are websites to do this or just get to a printer that has a good card stock.  I would put things on the back of the cards that meant something to the teams.  This could be personas – typical of those different people that use the software.  It could also be reference stories of typical work the team has estimated and done before for that number size.  These tended to be more useful and easier to guide the tempo of the voting than everyone using cell phones.

Flexibility is far more valued than rigidity.

For the project managers: Money burn down – yep we can still do it, even with story points.  This is done indirectly by empirical analysis once the system (team, time box)  has a chance to stabilize.  A project manager might take an average salary and at a sustainable pace (40 hrs a week), this means that our average velocity actually has a $ amount.  Though I don’t like doing this – it can bring in a sense of perspective for cost and priority. Is the team’s attention on this for a week worth the cost?   There are a LOT of intangibles though – like better quality and trust of the end-user. Sometimes there is an acceptable higher cost – because a team with the talent to do this more quickly is busy working on something with a higher priority and we are balancing the capacity of the program to complete the must haves in a release.

ANALOGY AND COMPARISON – This is helping us at one-level, think critically about what can be completed in a sprint… and the team teaches ourselves to become better problem solvers and know our capacity.

What we are learning how to be honest with ourselves, to tighten up sprint boundaries for what we can accomplish and show to the business as being complete and done.  We are earning some trust when done successfully.

It is the delivery of working software that truly matters.   The story point estimation is simply one level of thinking in order to view and assess the risk and size of the team’s commitment or forecast for several chunks of work.

 At first my concern for a new team is the commitment for this sprint.. but over time… we emphasize and cherish even more, the ability of the team to problem solve and right fit the stories into the sprint.  Then we get bigger about the work that fits into a release, and across a couple teams.

As ever, here’s to everyone being able to cut through a Gordian knot of their own.