Ham And Eggs

It is NOT an indicator of how much work the team is doing, right?

Too often, businesses seem to think that the resourcing we do during sprint planning to work out how many ideal hours we have, allowing us to decide what we can fit into a sprint, is an accurate reflection of how much work the team can/will do.

It’s not, OK, chill out. At BEST it’s a worse case scenario.

The average work day is 7.5 hours. That does not mean that I can dedicate 7.5 hours of work to tasks from the board. When we used to do resourcing, the business would estimate our resourcing for us:

There are seven people on the team doing a two week sprint, therefore, you have 490 man hours in this sprint, fit stories and tasks in that equate to those hours, you can have 15% of that figure for bugs.
-Somebody from the business

We quickly realised (well, as a team, we realised this was wrong immediately, but the business will always wait for empirical evidence first) that this wasn’t going to work. There is no way each team member can dedicate seven hours a day to the sprint. There are numerous things that vie for your time; getting a coffee, taking a piss, talking to colleagues, talking to the business, researching your industry, emailing your wife, checking your bank balance, rebooting your Windoze computer on a AD network which takes about 15 minutes, getting a coffee, etc, etc.

So, sprint after sprint failed (let me be clear, the sprints didn’t “fail” as the business always decided we “drop” something low priority from a sprint before the end but, as a team, that feels like a failure) and this could be down to bad estimating of ideal hours for tasks, true, but this is compounded by bad resourcing.

If you resource incorrectly, your entire sprint is undermined as it’s the basis for deciding what you commit to, you have an inflated idea of how many ideal hours you can deliver and so you over commit. Your gut feeling is always “this is too much work, we’re overcommitting!” but the math is right? So, it should fit in, right? RIGHT?

No, wrong. It won’t. Neither will pretending it will fit in and then dropping stories at a later stage work either. This will undermine the teams ability to deliver quality working software as there is always this grey cloud of unachievable stories hanging on like a bad smell at the end of your sprint backlog. The team will inevitably rush through what they’re doing to try and deliver what they’ve (been forced to) commit to. This is bad on many quite obvious levels, so I won’t spell them all out…

… OK, I will. This will result in less than polished code, rushed, hurried unit tests. Bothered and harrassed QA roles (if you have them) a stressed release manager as he’ll be backward and forward with UAT, an annoyed stakeholder as the stories get rushed, other annoyed stakeholders as their stories get dropped and, finally, a shoddy release of badly written, implemented, tested and released code.

Exaggeration? Maybe. But it makes my point.

If you ask each team member “How many hours a day can you commit to, ideally?” when you’re resourcing. You’ll get a worst case scenario on the amount of ideal hours you have. If you then estimate and plan based on that, you’ll ALWAYS deliver what you commit to (unless you get the planning REALLY wrong) and, usually, have time at the end to pick up an extra story, fix an extra bug, research a new technology or whatever. Everyone wins; the team are happy that they’ve delivered what they’ve said they would (and, maybe more) and the business is happy as they’ve managed external expectations and delivered the commitments and perhaps even more happy if another story was squeezed in, or an extra bug or two squashed.

I understand that you need to know where inefficiencies are, I really do, I want to know also. If the team are kicking around spending three hours a day reading XKCD and reading LOLCats, then I want to know as well and why. But they aren’t they’re spending the time doing actual work. So, let them do it and don’t force them into it.

If you want to measure time spent on things other than the sprint, then use something other than the sprint to measure that time. Resourcing and estimating/planning won’t help you here as they are, after all, just estimates.

You’re at sprint zero. You’ve got a new team. You’re new to scrum. You’ve never quite managed to stick to the Scrum framework. All reasons why you might not have a velocity. I’m sure there are more, but these are the most common. What do you do? How do you know how much you’re going to be able to fit into a sprint?

You guess.

Yes, I’m serious. If you’ve groomed your product backlog for the first sprint, estimated your stories and refined those estimates and broken down larger stories, then the only thing left to do is guess. Gather your team around and ask them “What do you think you can fit into this sprint?”. Once the team has picked from the highest priority stories and agreed that they think they can fit the work in, ask for their commitment. It’s at this point that you’ll need to help the team decide whether or not they’ve over committed. Most teams almost always start out thinking they can deliver more than they really have the capacity for. It’s not because they’re showing off, or because of any kind of arrogance, they actually do think they can deliver what they’ve said they will. Remind them that, while the stories are well written and the acceptance criteria well defined, they are just the start of a conversation with the business and things could change.

Your team will probably decide to knock of one or two stories and right now, that’s fine as they can always go back into the sprint if you find yourself running out of stories half way through. Once there’s a commitment, add up the story points. That’s your predicted velocity. It may not be accurate and it’s quite probably wrong, but right now, right this very minute it’s the most accurate idea you have of how much you can deliver in your sprint.

Why is this useful? Well, it will give your team a target, they’ll want to actually hit that velocity prediction as they’ve said they would. It’ll also come in useful for release planning and having some kind of vague idea of when your product might be delivered. You know least about how long or how complex a task is right before you start it, but now you’ve got some benchmark. You can add up the rest of the story points on your backlog, divide by the predicted velocity and have a figure which is roughly how many sprints you’ll need before you have delivered your product.

That is something that the product owner will shit himself with excitement about. Assuming he hasn’t asked you to translate that into a gantt chart.