Not surprisingly, everybody wanted one. However not everybody got the joke that it didn't actually exist - you could do everything it did, but you would actually need to build it using SOA/ESB/Integration tooling. (If you do actually want to build one, start here).
Another thing that everybody seems to want on their project is the Magical Progress Fairy. A lot of people think they already have one . . .
What is a Magical Progress Fairy?
A Magical Progress Fairy (MPF or latin: hopeus overexperiencus) is a mythical creature that you invoke when your project is not going as fast as you want it to, you're behind and you're likely to miss deadlines. It magically improves your productivity, vitalises your team, eliminates any problems and gets you right back on track - without you making any changes to your approach at all!I don't do that . .
Perhaps you don't - but do any of these things sound familiar?
"We only made 20 story points in our last sprint - to get back on track we need to make 30 in the next sprint"
So how is that going to happen? What are you actually going to do to improve productivity by 50%? A lot of the time we hear phrases like 'Everybody buckle down', 'Let's all really concentrate for this one' or 'we all need to work harder'.
On the other hand, everyone is already working hard and concentrating - and we need to keep in mind the Agile principle that progress should be sustainable indefinitely.
"We had a bad sprint last time - a lot of things came up to disrupt us"
And these won't happen on the next sprint? The internet won't drop out? A team member won't get sick? There won't be an unexpected bug in the tooling / database etc?
"We weren't experienced enough on the technology before - we're better now"
Maybe - but can you prove it? Are you sure you now know everything you need to know? What else is around the corner?
All of these approaches (some might call them excuses - I would never do that) rely on the Magical Progress Fairy to get you out of trouble. Magically progress will improve, mistakes will not be made, people will become more productive and disruptions will not happen . . .
OK, maybe I might need a Magical Progress Fairy - but what else can I do?
There are a number of things you might try but the first is to be realistic about what you've already managed to do and what you will be able to do in the future:
Accept reality and calculate your project velocity
Project velocity is a measure of how productive your team is, in your environment, working on your user stories, using their skills in the technology and method chosen for your project. It's not a single one of any of these, a measure of how 'good' the team is - or an individual. All of the project factors have a part to play.
To calculate your project velocity, simply divide up how many story points you actually managed to get done in the previous sprint by the number that you planned to deliver in that sprint.
Example:
We plan a sprint of 2 weeks (10 days). When we did planning poker we decided that one story point was going to be one 'ideal day'. We have a team of 5 people, so that gives us 50 ideal days, so 50 story points to plan with.
At the end of the sprint we found that we 'only' achieved 32 story points.
So, our velocity is 32 / 50=0.64. Note that it is not '1.0 - except for Bill had a dentist appointment and Sarah's PC needed a new hard drive, we spent time planning the sprint - and we used 2.5 person days for 1 morning of playback to the business'
Of course, you can have a velocity greater than 1.0.
If you'd finished all the user stories in 9 days - people do get ahead , then you'd have had a velocity of 50 / 45 or 1.11 (I know it's recurring but hey . .)
Once you know your velocity, use it to plan further sprints realistically
So, if your velocity was 0.64 and you have another 10 day sprint - then plan for 50*.64=32 story points
If it was 1.11 then plan for 50 *1.11=55.5 story points (if your planning poker has a 0.5 card - otherwise it's 55 - no quarts in pint pots).
Don't invoke the Magical Progress Fairy
If you planned 50 story points and you made 32, then that is what you made. No ifs, but buts. That's all you proved your team can make. Why will next time be any different?
Don't extend the sprint
'We'll be finished if we just have another day / 2 days / week / month . . '. One of the advantages of the sprint system is that it shows you 'point in time' progress with nowhere to hide. Either the software works or it doesn't. Software is often 95% finished for 95% of the time you ask the developer 'how it's going'
Finish early? Shut down the sprint, calculate velocity and start the next one
Congratulations - you made a velocity greater that 1 - but that just shows your estimating was on the low side vs reality. Now you know that, go ahead with that knowledge.
My velocity has changed after the next sprint - what do I do?
So, your velocity after sprint 1 was 32. Your velocity after spring 2 was 44. Great! This isn't the magical progress fairy. Something was different - maybe your team did get better, or the dev server didn't crash or there wasn't a big queue at the coffee shop.
So, use your new velocity to plan the next sprint- that's now our up to date measure of reality.
If you have put real interventions in e.g. given people faster computers, given them a copy of production data to test with etc, then this will allow you to measure if this made any difference.
A quick quiz - which of the following might actually work?
No prizes except maybe getting your project back on track . .
- Work evenings and weekends
- Increase the project duration by adding more sprints
- Adding more people to your project - see The Mythical Man Month
- Cut the scope by removing user stories
- Yelling at the team more - motivation is the key
- Re-prioritising user stories and revisiting what might be acceptable as a minimum viable product
- Re-plan the sprint every day: hey, why not replan every hour?
- Concentrate on the happy path and make some exception paths into a manual activity e.g. 'If paying by credit card, click 'next'. If paying by cash or check/cheque, please visit one of our high street stores'
- Add more RAM, CPU or disk to the development system - maybe - but is this the real issue?
- Cut/eliminate testing (especially NFRs) - let the users do it in the beta
- Try different sprint lengths - overheads like planning and playback can eat into the time. Beware long sprints as this reduces agility and means that progress can be obscured.
- Re-estimate everything over and over until we find an estimate we like that fits the plan.
- Ignore technical debt - we've gotta hit that deadline - hardcode everything!
- Calculate your velocity, use it to plan further sprints, bite the bullet and accept reality.
Finally, Beware the 'hidden hours' of evenings and weekends working - especially when you don't know about it!
Remember we planned for a 10 day, 50 person/day sprint? If 4 people worked the weekend, it's actually now a 58 person/day sprint. This may give you more development output but it's skewing your velocity!
It means that in the next sprint, you're now assuming that 4 people will work the weekend - and the same going forward.
If you plan for an 8 hour day and 2 of the team actually work 12 hour days all the way through 'to get it done and show dedication' - they're making a mockery of your velocity calculations.
Watch out for people staying late, doing work at home in the evenings of weekends - if they do it, you need to take account of it otherwise they're becoming your Magical Progress Fairy . .
