Freigeben über

We are going to miss... do we stretch out the Sprint?

  • Artikel

travel_by_trainWe had a really good discussion this afternoon between the 'agilists' in Microsoft on one of our discussion threads, and I wanted to share portions of the thread with the rest of the world.

Note: many of these folks are not bloggers, so I edited down their last names a bit. 

It started with this message:

We are close to the end of our second sprint. We have some major components that are almost complete but will not be ready for the Sprint 2 demo.

I was thinking…rather than punting half-baked tasks to the next sprint and also having nothing to demo but mockup functionality, should we let the major server components complete by adding a week to our sprint?  

The chorus of messages that came back were in unison.  NO. Do not extend the sprint!   Here are some of the (edited) replies...

Don’t do this. Disaster lies along this path – I know, I’ve made this mistake myself. I will never ever ever extend a Sprint again. Yes, it’s painful. You have a problem, and fixing problems can be painful.

It sends exactly the wrong message: the team committed, but now can’t deliver. If you bail them out now, they’ll expect you to do it again. 

[When using] a Sprint burn-down chart, the Team has known that they’re in trouble as long as anyone. [In hindsight,] they should have broken the items into smaller pieces that they could complete, prioritized work so that they’d have something to show, or aborted when it became obvious that the planning and goal was so far off as to be impossible to achieve.

Bill H. -- Deployment Technology

To the end of being ‘constantly shippable’, there is always a way to deliver some functionality in the time remaining. I’m not saying that it’s easy to see how to break things up along vertical slices (instead of traditional horizontal slices), or that it’s easy to carry through and deliver it, but there is a way. If you aim for that, you’ll get better at it. Doing this _is_ a skill, and it takes practice to get good at it.

Rohit E. -- SQL Server

I advise you to not change dates. 

Furthermore you shouldn’t demo mock-up functionality, but instead should demo what you have. 

I’ve always tried to keep the sprint review demo’s unpolished and unedited. So, show the good, bad and the ugly. I think in many ways we’re afraid to show poor functionality, half-baked features, etc when in fact this is precisely what is needed for the stakeholders to get as clear a picture as possible of the actual state of the project.  Better to be completely up-front. This also spills over to how you deal with customers (complete transparency).

You should avoid making the demo look nice (implementation) without the unit tests and scenario tests enforcing requirements (testing). 

When the sprint deadline is close, it’s very tempting to put effort into implementation and make up testing work in the next sprint. That’s not a whole ship cycle in an iteration and it’s a dangerous game to get into because you’ll continue to spiral by always having testing behind.

Allen D. -- Dev Div

If you extend a sprint, you set up a pattern where the sprint end date isn’t real, and on every other sprint, the team will (rightly) expect that you will extend the sprint for them if they are a little bit late.

If you can demo stuff, you demo it. If not, you don’t demo it.

Eric Gu.  

+1 – Never extend a sprint. A sprint should not have “exit criteria”.

Also, be careful about how you evaluate the sprint, saying the team failed in the execution of the sprint is most likely the wrong perspective. Most likely the biggest issue was in the sprint planning. I almost always see teams try to do too much in their early sprints until they get realistic about what they can actually achieve in a month.

My recommendation, plan your next sprint more realistically and allow some variability. One good way of doing this is splitting your sprint plan into “Required” and “Bonus” work for the sprint. Make sure the “Required” work can always be done in less then the sprint timeline, but your required + bonus work could not be done in the sprint.

For example, plan two weeks of “Required” work and four weeks of “Bonus” work. This helps improve your predictability because you’ll know the required stuff will get done, and also makes sure the team won’t run out of work before the sprint end. Remember that there is no such thing as a perfect estimate, so if you try to plan exactly a month of work, you’ll always be wrong with a 50/50 chance whether you’re over or under. 

With 2 weeks required and 4 weeks bonus, then the team can be up to 100% over their estimate and still complete the required work, or 33% under their estimate and still not run out of work. If your teams estimates get more accurate then you can plan 3 required and 2 bonus, but never go to just 4 required.

Jonathan W. -- Server and Tools

One of the guiding principals of agile is building customer trust. There was a great session of experience reports yesterday here at the Agile 2007 Conference on this subject. If you tell your customer you will have something done on a certain date, you need to deliver.

If you can only get part of it done, it better be darn close to perfect and released on time, and the next sprint better deliver the missing functionality in perfect condition and on time. If you just push out your deadline, trust from the customer, and confidence from the team will errode.

I think it is also extremely important to the team to be able to say, "This spint is done." By lengthening the sprint, you lose sight of the end, and the team can lose focus on the goal. Some schools of thought say to celebrate even the small successes. Acknowledge the stories that are done done done. Acknowledge what is left to do. Figure out why you weren't able to finish and make a plan to overcome that in the next sprint.

Robin P. -- Windows

And what did I get out of all of this?  The undeniable fact that Microsoft has some very passionate agilists in nearly every part of the company, each using agile methods to deliver 'trustworthy computing' one sprint at a time.

And in case you haven't heard me say it before, this is the best place on Earth to be a developer... hands down.

Comments