Marcato

Agile is a set of principles to guide how you organize and function as teams and Scrum is a particular system for establishing and building a delivery rhythm within that team.  Part 2 examines 5 more examples of common changes made to Scrum and the reasons why these are counter to what the system is trying to accomplish.

6.  Set “stretch” goals by putting more stories in the sprint than fit within the velocity

To create a sustainable rhythm, you have to set goals for the team that can be met with regularity.  If it requires heroics to accomplish one sprint, then heroics become the norm for future sprints as your team velocity adjusts to account for this.  New teams often fall prey to this phenomena – their energy for the project and desire to make a good impression on their product owner gets the better of them.  They let the product owner put more stories into the sprint than is prudent because their uncertainty about their actual velocity opens the door for the usual optimism of a development team.  They try to shoehorn in just one more story because they are interested in the technology or feature and want to try to make it fit.

Japanese Lantern Lighting Festival, Como Park

This kind of persistent inflation in velocity is unsustainable – like with any economy, real growth can only come from an increase in resources or in the productivity of the existing resources.  You will see this happen through the productivity that comes from climbing the learning curve, but that always levels out eventually.  What’s the downside?  In the short run, disappointments happen, and instead of giving the team the opportunity to establish and celebrate a pattern of successes, they are instead frustrated by a string of missed goals.  In the long run, left unchecked this behavior leads to burnout and turnover as you find yourself trapped in a “death march” of unsustainable expectations.

7.  Give credit for a story when it is not really done (shippable)

Yes, it feels good to show off your work in the sprint review and to claim victory, but with each passing event where “done” is not really done, your team has taken on a future debt that must be repaid.  These schedule bombs don’t go off until much later, long after the fuse is lit, and usually at the most embarrassing and inconvenient times.  Also, once you compromise on this a little it becomes a slippery slope of lowering expectations as individuals vie for credit for their work.  We all know that product owners can be fooled in a demo, so acceptance by the product owner is not really enough.  Instead, the scrummaster and testers should hold firm to the team’s definition of success and only agree to take credit when credit is due.

8.  Increase length of sprint so that more stories can get finished

It’s the day before the end of the sprint and you can see that there are a couple key stories that are not going to make it.  They are big stories, so without these your velocity will be less than half what you expected and the optimistic outlook from the team is that they could get them done if they only just had one or two more days.  Someone on the team suggests that it would be better to extend the sprint than to arbitrarily end it now when you are so close.

Japanese Lantern Lighting Festival, Como Park

Usually this behavior indicates several forces are at work – stories are too big, too many stories are being worked on in parallel, and the team may not be doing enough detailed planning at the start of the sprint to have clarity on what will be built.  Since software is a gas that expands to fill 110% of the space provided, if you extend the sprint to let that last 10% in, then you will learn nothing from your mistakes and just do the same for the next sprint.  You also sacrifice your rhythm, these last minute changes in expectations confuse everyone as you try to figure out who has the authority to change the rhythm and who is responsible for communicating the new plan.  Leave the plan alone, examine in your retrospective what really went wrong, and fix it so it doesn’t happen again.

9.  Cut sprint short because all “bought” stories are complete

Japanese Lantern Lighting Festival, Como Park

This is more of a “minor sin”, but interrupting the rhythm just confuses everyone – you are better off to find other small stories to add to the scope until the time is up than to break the rhythm.  Be careful not to start big stories that you can’t finish – this just leaves the product in an unstable state as you are trying to demonstrate it and threatens the principle that the product be shippable at the end of the sprint.

10.  Estimate during sprint planning meeting

This observation is controversial as there are certainly going to be situations where you are forced to do this by no apparent fault of your own, so if you find yourself in that situation, then by all means just do it.  But first understand the risk you are taking – you are estimating the story in isolation, perhaps by a different collection of people than normally estimate, and you are doing so in the context of already knowing you want it in the sprint and you just need to decide if it will fit.  This probably means you already know how big you need it to be, so you are anchored on this answer.  What happens in this situation?  The estimate comes in to magically fit and round out the sprint and the most common reality is that you underestimated its complexity.