Tag Archives: scrum

Scrum it like a toddler

Most people (reading this blog at least) are familiar with the format of the Daily Scrum, where everybody on The Team comes up with an answer to the following three questions:

  1. What did I do yesterday?
  2. What am I planning on doing today?
  3. What impediments do I see?

But what a lot of people don’t seem to realise is that this is pretty much all there is to Scrum.

Scrum is pretty much just these same three questions repeated over and over and over again.

Don’t believe me?

At the Sprint Review the entire Team answers the question: “What did we accomplish last Sprint?”

And at Sprint Planning the Team again answers the question: “What are we planning on doing in the next Sprint?”

And finally at the Sprint Retrospective we are ask and answer the question “What impediments do we have? (and what are we going to do about them)”1

And of course the very same pattern can and should continue to repeat at the Release Level if you have one.

It’s far too easy to get caught up in the mechanics of Scrum — at which point it starts looking like a laundry list of artefacts to create, time boxes to keep and meetings to attend – but IMO that’s overcomplicating it.

All you have to do is connect with your inner 3 year old and keep asking (and answering) the same three questions over and over and over again.

“Just keep Scrumming, Just keep Scrumming”


  1. Careful readers will notice that the meetings could be considered to be out of order. That’s because the Daily Scrum Questions IMHO are out of order too! It’s far more effective to discuss what has been done and what impediments have been uncovered before figuring out what you’re going to do next. 

Not Original Artists

When I was in school, there existed a very popular packaging of music which I remember as “Hits Picks 100!” – basically these were compilations of all the songs that had been “on the charts” for the last few months. I guess in many ways it was the precursor of Napster – teenagers wanting to consume giant bags of unrelated popular music instead of albums from a single artist.

Anyway, there was sometimes a catch. Occasionally a very sheepish looking individual would arrive at school the next day, having spent all their hard earned cash on one of these massive compilation albums and when questioned about how it was1 – the reply was “Not Original Artists”

I don’t know the specifics exactly, but to keep costs down to the bargain basement prices that have ever attracted the younger purchaser, the publishers of said massive compilations would not licence the original recordings, but instead have somebody else effectively “cover” the song for the album (with varying degrees of success I might add)

There were of course legitimate compilations made, but these tended to attract higher prices. The two products looked the same, and so the average consumer assumed that they were the same.

Now of course to protect themselves legally, the advertising and packaging had to contain somewhere the dreaded “Not Original Artists” labelling – but nobody ever said how big the font had to be…

Inspired by the movie…

A few years later, a similar thing started to happen with Movie Soundtracks, which were equally as popular at the time as the pop compilations were a few years early. I’m not talking so much about Epic Original Scores such as Star Wars here, but rather more pop culture outings such as the soundtrack to Bas Lurman’s Romeo and Juliet.

These again were compilations, but this time around they were based around a curated set of songs chosen as the background for a particular movie.

Now these albums were created from licensed music and they were also combined with the licensed movie property. (No wonder they were popular!)

Hoards of people descended on music stores to buy these soundtracks and reconnect with their favourite movie.

In some ways, the movies became ads for the CDs. I think this was especially “a thing” in the days when you had to wait a year or more to own the movie yourself or even rent it from a video store. The music however you could get right away.2

But the popularity of this format once again drove marketers to exploit this demand by creating something that looked like the popular thing but wasn’t actually the popular thing.3

I remember being given an apparent movie soundtrack by a friend, putting it on to play and then halfway through thinking “I’ve seen this movie twice, but I don’t remember any of this”

So I went back to see the movie a third time, then went home and listened to the soundtrack again – to once again be baffled. Until I inspected the case a little more closely and found the phrase “Inspired by the movie…”

Inspired by Scrum

So how does this relate to process?

I think there is a lot of “Inspired by Scrum” out there that people are calling Scrum.

Who knows the full set of reasons why people do this4, sometimes it might be because people never saw the (Scrum) movie and don’t know that what they’re doing isn’t really Scrum.

Sometimes it might be just like the Hits Picks CDs – Scrum looked too hard and too expensive, so let’s do a cover version instead! Hey, it looks right doesn’t it?

Or maybe Scrum just wasn’t plain right for you and you’ve come up with something a lot better. And for some reason you’ve decided to call it Scrum anyway.

But for whatever the reason, it’s not Scrum, so please don’t call it Scrum.

Why does it matter what I call my process?

I think it matters for a few reasons, but here is the main one:

There are no end of people and blog posts out there who say that Scrum is awful and should perhaps “die in a fire” and then they describe the process that they were following and yes, it’s usually awful, but it’s also never Scrum.

Just once I would like to hear or read an “I hate Scrum” rant that actually describes Scrum.

But this distracts from the real issue – and the real problem is that you can silence that argument with “Oh, but what you were doing wasn’t Scrum”

And that’s the problem.

Because that answer presupposes that Scrum was the right thing for these people to do.

That is to say that doing Scrum correctly would have solved all their problems. Now maybe it would have, but that’s beside the point5. You can no longer have a sensible discussion about it because we’ve placed all the blame on Scrum.6

You can’t judge a process if you’re not following the process.

So what should we call our process?

Scrum Butt?

Scrum Butt was a popular term, I dunno, maybe 5-6 years ago? If you don’t remember it, the concept came from people saying “Oh we’re doing Scrum, but we don’t deliver working software at the end of each Sprint”

As cruel as it sounds, it was useful in the beginning. Because the people who genuinely wanted and needed Scrum often skipped over the active ingredients of the process and thus didn’t get the benefits. And thus “Scrum Butt” was originally a playful way of saying “Yes, I’m totally on this diet, except I’m still eating as much as I want”

But at some point in time, it suddenly became “NOT OK” to say Scrum Butt – I remember one guy at an agile conference basically losing his mind at a panel who just told him that he was doing “Scrum Butt” because they were being abusive and not helpful (Frankly, they both had a point, what he was doing was not remotely Scrum, but telling him to simply do Scrum properly wasn’t very helpful either, because that simply wasn’t feasible for him. He knew what to do, it was his company that would not permit it)

So in these days of “little ‘a’ agile” saying Scrum Butt might seem harsh, but it was at least clear.

Scrum-like?

So in order to salve egos and increase sales we got Scrum-like. This to me is the “Not Original Artists” of process naming.

The problem with the phrase “Scrum-like” is that it begs the question “In what way?” – because 9 times out of 10 the primary way in which the not-Scrum process is “like” Scrum is in the way it looks.

Inspiration over Like-ness

I think it’s more accurate, and dare I say transparent to say that your process is “Inspired by Scrum” rather than “Scrum-like”

The “Inspired By” CD’s were true originals – both artists and content. Sure they weren’t in the actual movie, but a lot of the time that didn’t matter, they were still good songs. (most of the time)

And some people even preferred the “Inspired by” CD’s to the Sound Track CD’s and that was OK too.

So if you’ve been inspired by Scrum, in whatever way then own that. Don’t feel compelled to pretend you’re doing something you’re not. Don’t wimp out and say you’re “Scrum-like”7own your originality.

Claim inspiration and invention, not mimicry.

And then we can leave Scrum to mean, well Scrum.


  1. Which was code for “Can I get a copy please?”. Napster didn’t create the concept of “sharing” music it just scaled it. 
  2. And who doesn’t love a fast feedback cycle!? 
  3. In those days there was a less torrential stream of movie production. 
  4. Scrum is of course also not unique in this regard. 
  5. The is a secondary problem here which is we never get a decent chance to talk about the problems with Scrum itself – because we’re too busy telling people what they’re doing is not Scrum. 
  6. For what it’s worth, I’ve seen the same thing happen to kanban. 
  7. The process equivalent of using a really small font. 

The parable of the water

I was out for a walk the other day with some friends and their family. About halfway through the walk one of the boys declared that he was thirsty. No problem says Dad, here is $2, there are some shops, go buy yourself a bottle of water. The boy runs off. I think no more of it.

A few minutes later, the boy comes running back to his father, not with a bottle of water, but rather with the same $2 coin. He gives the coin back to his father and simply said “Mum says no”.

Curious I think. Why would a mother deny their child a drink of water?

Later, I discover why.

“I denied him the water, so that he’d learn to plan better next time, so that he’d learn to learn from his mistakes (however small they may be), and to eventually come to the understanding that almost all his decisions have consequences of some kind.”

At the time I thought “Wow, that’s a really great mother”

And this morning I thought “Wow, that’s a woman who really understands Scrum”[1]

These rules are here to help

I think something that has perhaps been a bit forgotten is that the Scrum rules, much like our mothers, are here to help. We may not always want to do what they’re suggesting, but oftentimes it’s exactly when we want to the least that we need to the most.

The most obvious parallel to my water bottle story is one of the most hated[2] rules in Scrum – being:

    The Product Owner may not change their mind during the Sprint

This is often quoted as the reason that Scrum is “not Agile”[3] but there are several good reasons for it.

The one I want to highlight today is simply “So that our Product Owners can learn to plan better

Imagine speaking to the ScrumMaster after they had denied the Product Owner a mid Sprint change if they explained:

“I denied him the change, so that he’d learn to plan better next time, so that he’d learn to learns from his mistakes, however small, and come to an understanding that all his backlog prioritisation decisions have real world consequences of some kind”[4]

Doesn’t sound so bad now, does it?


  1. Not the letter, but the principles. It’s quite possible that she’s never heard of or has any interest at all in Scrum. And I’m certainly not suggesting that she’s using Scrum to raise her children.  ↩

  2. And by association, one of the least followed.  ↩

  3. Often by people who define Agile as flailing around building random things based on whim.  ↩

  4. I can imagine that I’ve actually outraged some readers at this point by suggeting to them that their Product Owners don’t consider the consequences of their actions before acting. Well, I have two responses to that:

    1. I’m pretty sure not all of them do, so count yourself lucky if this is not the case for you

    2. Even some of the best PO’s may be new to the concept that their Backlog prioritisation decisions have immediate effects on both the finances and morale of the organisation. This seemingly annoying minor Scrum rule is designed to help them remember that.  ↩

Have you Mastered the Basics?

So I’ve noticed a trend in recent years. Whereby a lot of people are hungry for “advanced” Agile and Lean techniques (whether it be at a conference, in the classroom or in a coaching engagement)

So far so good, both Agile and Lean have been around for decades – and so it should not be a surprise that people are passed the basics and ready for some more advanced stuff.

But a conundrum often arises in these situations whereby the organisations and people most eager to learn the more advanced techniques are the very same ones that are yet come to grips with (let alone having mastered) the basics of Agile or Lean.1 (This is obviously a generalisation and not true in every case, but it’s sufficiently widespread for me to consider it a trend)

As I tweeted back in January:

And talking to other established consultants, trainers and practitioners it seems that I’m not alone in this observation.

So what’s going on?

There seem to be two fundamentally different views on what “the basics” are actually comprised of.2

And these two views may be an attribute that is unique to (or at the very least exacerbated by) the very nature of Lean, Agile & Systems Thinking.

(So again making a gross generalisation here)

Many people tend to class the basics as things that you do.3

Whereas “we in community” tend to class the basics as concepts you understand.

And thus many feel that they have mastered the basics when they can go through the motions – they write things on post-it’s or enter them into a tool – perhaps they set WIP limits, and they almost certainly know which three magic questions lead to hyperproductivity

But because they’ve not mastered the basics by the community’s definition – they often fail to yield any benefits from these changes (sometimes they do however, but that’s a topic for another time) – and thus they feel the hunger for something more advanced. Something more to do.

So this explains the phenomena – at least to my satisfaction – but it does not necessarily provide an answer 😉

Except perhaps that we should more carefully consider how we use our language and how we label things; because Basic Practices != Fundamental Concepts.4


  1. This does however put me in mind of an episode of House (“House vs God”) – where Wilson convinces a child who believes that he is a saint and thus does not need surgery to have surgery through the argument that an actual saint would have the humility to believe that they were in fact just sick and not in fact special. 
  2. This being an entirely different question to “what the basics actually are” – I’m arguing ontology here. 
  3. As soon as you do that, it’s also easy to apply models like Dreyfus 
  4. Ease of measurement and evaluation plays a big part here too. It’s much quicker and easier to determine whether or not somebody is having a 15 minute Daily Scrum than it is to determine whether or not everybody has internalised the value of (say) slack. 

Using Narrative as an alternative to rules of Best Practice

In my last post, I spoke about the limitations of Best Practice.

I can imagine that some of you may be thinking:

“Well Mr Bennett, it’s all well and good to poke holes in rules of Best Practice, but what do you suggest we do instead!?  We can’t just have a free for all!  How will people know what to do?”

A free for all is not at all what I’m suggesting.  In fact far from it.  The deep and lasting irony about using Best Practice outside of its appropriate domain of use is that you get less actual control as people game the system to get around it.

Let’s use a concrete example to illustrate the point I’m talking about.

You might for example be using a process control framework (let’s call it Scrum) – and you can have a simple rule:

Rule A) “Only the Product Owner may abnormally terminate a Sprint”

OR

Rule B) “Only the Team may abnormally terminate a Sprint”

OR

Rule C) “Either the Team or the Product Owner may abnormally terminate a Sprint”

There have been passionate discussions (mostly online) as to which one of these rules is “right”, and evidence of one kind or another exists to support all of them.  Clearly, as written, they cannot all be right.

Which one is Best Practice?

Rules are used to guide behaviour and also provide an objective justification for punitive action towards rule breakers.

In our society we are all aware of the punitive actions associated with our criminal justice laws.

But terminating a sprint is a process rule, not a criminal justice law.  If a criminal justice law is broken, it is used in a court of law in order to provide guidance as to whether the rule was in fact broken and what the appropriate punishment should be.  When was the last time this happened on your project?

Process laws are therefore less about punishment and more about guidance.  But how suitable are rules for this purpose?

Rules like these unfortunately offer very little guidance for complex situations.   And the more general they are, the less guidance they seem to offer.  You could easily argue that Rule C could be replaced by “Anybody except the ScrumMaster may terminate a Sprint” – it may sound silly, but really, what is the effective difference between that statement and the rule as described?

The problem with rules is that to be clearly enforceable, they need to be pretty specific – which is OK when your rule genuinely is “Best Practice” because everything else apart from following the letter is going to be an undesirable outcome.  But if anything less than perfect is your aim, then simple statements such as “Only the Product Owner may terminate Sprints” begin to lose their utility and we instead direct people towards a “not terrible, but not great either outcome” – in many cases like these, the focus tends to be not on excellence but instead on preventing horrible failure.  The problem with this approach should be obvious, you drag down the great outcomes to protect yourself from the bad.  Maybe it’s me, but I don’t see a competitive advantage in that approach.

Narrative is a good option – in these series of narrative fragments I have provided an alternative to simple rules – and one in a very human form, one in which our race has been learning and passing on knowledge for centuries.

Instead of a single point, instead there is a rich tapestry of guidance and learning.  One in which the team and organisation can add to themselves over time as they share their successes and failures.

Rules & Narrative Fragments

Sprint Termination Narrative Fragments

NOTE: If you’ve arrived here directly this is a set of narrative fragments edited together to become a fable.  The purpose of which is to socialise desired behaviours within an organisation.  It is presented as an alternative to stating and enforcing simple rules along the lines of “Only the Product Owner may abnormally terminate the Sprint” and instead attempts to capture the richness and subtle involved in such decisions.  Like all good fables, it also contains several other minor lessons.

A LASTing Benefits Scrum Fable

Our Protagonists:

Bob – The ABC Corp Product Owner, recently married

Sally – The CEO of ABC Corp, & Bob’s boss

Gareth – The CEO of Company X

Jim, Gary & Peter (aka the Three Amigos) – schoolmates who now find themselves working on the same Scrum Team at ABC Corp. They all hold a large number of options in ABC Corp stock.

Betsy – the Scrum Mistress at ABC Corp, nobody’s boss

A Conscientious Product Owner

Bob the Product Owner being recently married is going on a long honeymoon. Knowing how important a Good Backlog is to the success of the ABC Corp Product, Bob grooms far ahead and spends quality time with his team ensuring that they have the information they need, and know what is expected of them whilst he’s away.

A Deal in the making

Sally (ABC Corp) and Gareth (Company X) having been working together on an exciting new joint venture for some time. They plan to build on the natural synergies between their company’s respective software suites and create an entirely new class of product which should take the market by storm.

Work needs to be done at both organisations. Their respective marketing departments have also requested that Gareth and Sally provide some kind of indication of when they think they can deliver it to the market.

Sally and Gareth get their respective software teams together to estimate how long the integration effort might take.

Both companies use Scrum for development. The estimates produced by the teams indicate that at the current rate of development, it’s most likely that the work will take between 4 & 6 “Sprints” to complete the integration. Marketing immediately calculates a calendar date from this information and starts working on Press Releases and Marketing Collateral.

Bob returns with a smile and a sunburn

The day after the deal is signed, Bob comes back to what appears to him to be a very different organisation to the one he left!

There is a note on his desk that he’s to see Sally the very instant that he gets into the office.

Swallowing back the fear that he’s going to be fired, Bob checks his grooming in the mens room before taking a deep breath and going to find Sally.

Sprint the First – Responding to Change over following a Plan

Sally briefly explains the deal she made with Gareth while he was away and directs him to start work immediately.

Bob explains patiently that he will most certainly prioritise the work in his “Product Backlog” but that “his” team cannot start on the work for a least another 10 days, as they’re currently “in Sprint”.

Sally explains to Bob, that time is of the essense, wheels are in motion and that 10 days is far too long to wait to get started.

“Bob, irrespective of what the team is currently doing, it cannot compare to how important producing the Joint Venture Software is. We need this.”

Bob stands firm.

“No!” he says, “I cannot break my promise to the team! As the PO I committed to not changing my mind about what the team is to deliver in each Sprint. If I break my commitment I’ll go to Scrum Hell! I’ve seen pictures in Betsy’s Scrum Bible, and it looks horrible!”

Sally considers firing Bob on the spot, but his mention of Betsy’s Scrum Bible reminds her of what’s in her bottom drawer. She opens it and takes out the gold plated plaque that Betsy gave her last Xmas. It is inscribed with something called “The Agile Manifesto for Sofware Development”, she scans it quickly to find the text she’d thought she remembered seeing.

She holds up the plaque and begins to read from it.

“We Value… Responding to Change over Following a Plan”

“Sounds to me Bob, like you’d rather follow your plan, than respond to the change I’ve just given you!”

“Um”, says Bob as he becomes increasingly fascinated with the top of his shoes.

“But wait, there’s more!” exclaims Sally

“We welcome change, even late in development, Agile processes harness change for the customer’s competitive advantage”

“Right Bob, I’m your bloody customer and I can see some obvious competitive advantage to hand here and I’m asking you to harness it for me!”

“But, Scrum Hell…” says Bob.

“You need to make a choice Bob, do you want to be Agile or do you want to follow the rules of Scrum to the letter? I had, until this point in time, thought that the entire point of doing Scrum was to become more Agile, not to be drowned in process and buracracy! It seems that I was mistaken!”

Bob is flummoxed. He thought he’d been such a good Product Owner, but now he felt himself torn between following the rules of Scrum and avoiding Scrum Hell or “being Agile”.

And then he thought of the solution.

Betsy. Betsy would know what to do. Afterall, this was a matter of process, why wasn’t she here?

Well Duh!

Sally called Betsy into her office, and they retold the story.

“No Prob” she said.

“Just Abnormally Terminate this sprint and then plan a new one. Bob avoids a painful eternity in Scrum Hell and you get your fancy new software built sooner rather than later. Just make you explain to the Team the reason as to why you’re doing this”

And so they did.

Sprint the Second – A series of unfortunate events

Jim, Gary & Peter have known each other since high school.

The news of the joint venture has delighted them as it means they now have a real chance to become squillionaires.

So when Bob announces the termination of the Sprint and the reasons underlying the change, they plan the new Sprint eagerly with the rest of the team.

And then they make a plan to celebrate…

And so they did.

Quite enthusiastically.

In fact they were so enthusiastic that they now can’t come into work for at least the next 6 days whilst their wives raise the bail money.

The rest of the Team optimistically soliders on for a few days, but after 3 days, all indications are pointing towards the cold hard fact that they’re on a Fool’s Errand. They can no longer deliver on their Sprint Commitment. Not a chance. Bail has been raised, but the three Amigo’s won’t be released from the county lock-up until the end of the Sprint at the earliest.

They ask Betsy what to do and she tells them that they need to tell Bob ASAP. She recommends that they agree to terminate this Sprint (as it’s no longer viable) and plan a new one, one that is achievable with the staff to hand but still progresses towards the overall project goal. Since Bob has just learned about abnormal sprint terminations, Betsy doesn’t forsee any problems and so lets the Team see Bob alone and heads off to her dentist appointment.

The Team meet with Bob. Bob goes ballistic. He tells them that he kept their commitment to them, and that they therefore need to keep their commitment to him.

The Team try to explain that the basis on which they made their commitment no longer exists. After all, if they could still deliver, why would they ever have originally needed 7 people to accomplish the goal?

Bob won’t hear a word of it. As far as he’s concerned, what the team is working on is “Super Duper Best Lucky Priority #1 Urgent Stuff” and he’s already terminated one Sprint already, surely terminating two in a row can’t be allowed. He decides it isn’t and tells the team so. Betsy said he could abnormally terminate a Sprint, not Sprints and anyway, he wants it done.

So Bob draws on his previous experience in “motivating” people and threatens the team: “If you don’t make your Sprint Commitment I’ll take the espresso machine out of the kitchen and dock all your bonuses by 20%”

The Team, horrified, nod acquiecense.

Dejected and feeling hopeless, they settle on a plan.

“Well, we could create the appearance of delivering this work, if we seriously compromised on quality and developed againt the current Alpha of Windows 9 – after all, it has a lot of what we need to do already built in”

“That’s hardly ‘Potentially Shippable’ though is it?” somebody asks.

“Who cares, he asked for something completely unreasonable, so let’s give it to him”

“Just make sure Betsy doesn’t find out about what we’re doing. She’ll go mental

And so they do.

Sprint Review

As per the plan, the Team develop a plausible facimile of the features requested. It only works on the latest Alpha Version of Windows 9 of course, but this is not at all apparent at Sprint Review.

Bob and Sally are both delighted. Bob secretly compliments himself on his management prowess.

Jim, Gary and Peter, recently released from the lock-up, sit at the back of the room, nursing their wounds and wondering how the team pulled off this miraculous achievement. But the mood in the room is so positive, that they say nothing.

Unintended Consequences

As part of the arrangement between ABC Corp and Company X, at the end of each ABC Sprint, ABC delivers the latest codebase to the Company X team. All this happens without the knowledge of the ABC Corp Scrum Team.

When the Company X team get their delivery, they are unsurprisingly less than pleased. The code is effectively useless, there are no tests, it’s full of bugs and it ONLY runs on a version of Windows that’s not expected to ship for 3 years.

They immediately tell Gareth, who turns a deep shade of beetroot red and immediately leaves to meet with Sally in person.

After her meeting with with Gareth, Sally considers taking a leaf out of Don Drapers book, but thinks better of it and settles for a deep breath and a walk around the block before going to see Bob. This time she remembers to make sure Betsy’s there too.

After some spirited discussion and finger pointing, Betsy soon uncovers the the root cause of the issue. She patiently explains to Bob and Sally that if the Team thinks the Sprint is no longer viable, and they can point to clear reasons why they think this is so, it’s probably better to listen to them than rely on wishful thinking and threats.

Sprint the Third – Life is hard and then you die

After a few false starts, and the addition of three new members to Alcoholics Anonymous, ABC Corp is ready to start work on the deal of the century.

With a full team, and an adjusted release plan, and under the watchful eye of Betsy, the Team plan to fix up the mess they made last sprint and then start on some entirely new functionality.

The Sprint Plan looks good, and they get to it.

However, halfway in, they discover that the map is not the territory. Design information that they had been given by Company X, information on which they’d based their initial estimates has turned out to be completely incorrect. To make matters worse they’ve also discovered areas of the Company X codebase riddled with technical debt. This is going to take a lot longer than first expected. So long in fact, that the seemingly perfect Sprint plan now seems impossible.

The mood is dark, most of the team would rather quit than ask Bob to terminate the Sprint again, but Betsy is adament and the three Amigos are game.

Bob discovers calm rational thinking

Bob, somewhat a changed man from his experiences to date, listens patiently. Bob and the Team discuss what the problem is, and what the impact is likely to be. They identify work that clearly cannot be done this Sprint, and descope it from the Sprint. Bob agrees to communicate this upwards to both Sally and Gareth. Sally should be pleased at least that this time it’s Company X at fault.

However, the team is concerned that this is still not enough and push to terminate the Sprint again.

Bob furrows his brow in deep concentration and asks them “So tell me why you want to do that?”

The Team stares at Bob blankly for a moment before replying

“Well it’s obvious isn’t it? We are no longer certain that we can meet our commitment, so we have no choice but to terminate the Sprint!”

“And then plan a new one…” says Bob.

“Yes, of course and plan a new one” chimes the Team.

“A Sprint Plan to do what exactly?” asks Bob.

“Turn the Product Backlog Items of Highest Priority into Software of Potentially Shippable Quality” the Team parrots back.

“Which are?” asks Bob

“Whichever ones you say are the highest priority, Product Owner, Sir! Yes Sir!” the team says in unison.

“Well I say the ones remaining in the current Sprint are the highest priority” said Bob.

The Team goes quiet until somebody mutters “But the code is a mess, we don’t know how long it’s going to take to do this…”

“But it can be done?” asks Bob?

“Well yeah, we’re pretty sure about that, just not how long”

“Do you think that there is a chance that you can pull it off in the time remaining in the current Sprint?”

“Well yeah, sure, there is a chance” says the Team “And even if we don’t get it all done, by then we’ll probably have a clear idea of how much longer it’s going to take, because we’ll have come to terms with it”

“Well, then get out of my office and go to it! We’ve agreed to descope the work that there is no chance of getting, and I’ll set expectations upwards about that. We’ll use the Sprint Time Box as a safety net. Try as hard as you can to solve the problem and we’ll see where we stand at the end of the Sprint.

“You know what to do so I’ll leave you alone for the rest of the Sprint to get on with it. Go wild, be creative, do whatever you need to do to figure this out and get this project back in control, if not moving forward”

And so they did.

Sprint the Fourth – Plain sailing

Sprint 4 proceeds without incident. Now aware of the technical issues and having fixed many of them this time around the team commits to a comfortable amount of work, and produces it all to the pre agreed definition of Done.

At the end of the Sprint it all integrates perfectly.

Jim, Gary and Peter start to peruse boat catalogues…

 

Creative Commons License
Sprint Termination Narrative Fragments by Simon Bennett is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.

Permissions beyond the scope of this license may be available at http://lasting-benefits.com/contact-us/.