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.

Sir,

Scrum is not about keeping the faith, I am completely committed to scrum, as, I think, are you. It’s about hearts and minds. American military generals bang on about it all the time and for good reason. For months and months we’ve been calling it a “stand up” or a “scrum” and, on the very eve of launching our latest product, which was designed, written, managed and launched using scrum, we switch to calling it a “huddle”. What this says, unconsciously perhaps, is that we stopped doing a standup and when we switched to a “huddle” the product got launched; not a good advert for doing scrum.

Might sound like a bunch of crap, but it’s all psychologically sound.

We are a scrum team, regardless of whether we’re actually in a sprint, if we all stand up at the beginning of a day, then we’re doing a stand up. We can do a huddle if there’s less people and it’s at a different time of the day, maybe. There are ceremonies and artefacts of Scrum and the last time I looked, a huddle wasn’t one of them. The rules are few, simple and really easy to follow. Breaking them, for whatever reason, should not be done. If you’re breaking the rules of Scrum, you’re NOT doing scrum! Simple as that. If you break the rules of chess, while you’re playing chess, you’re not playing chess and you’ll probably get a punch on the nose from your opponent for cheating to boot.

One of my responsibilities as a scrum master and dedicated member of the team is to improve the scrum process, this can only be done with more and more business buy in – if we start diluting it now, then we take two steps back. The product got delivered BECAUSE OF scrum, not in spite of it. Without scrum it would have been a different story (probably wouldn’t have failed, but it wouldn’t have been launched yet). I can only do my job with the help of the team and, although I don’t think you called it a huddle because you want to rename the standup to huddle, I need your support in pushing through scrum, which includes not diluting it.

Do you understand my point? It’s about cohesion and making sure we’re always an advert for ourselves and the way we do things and the reason for doing things and that we get things done BECAUSE of the CHOICES WE MAKE as a TEAM on how we do the things we do.

Kind regards,

Mike Pearce

Our team sits in a horse-shoe shape where I work. Some people on the inside and some on the outside. There are no partitions, no borders and people only really put their headphones on when they REALLY want to get in the zone. Communication is key to having an effective scrum team and in this shape, totally co-located (even the DB team are in the horse-shoe and they’re not even part of the scrum team!) means communications is but a chair twhirl or a lean over the desk away.

So, with this much communication going on, is the daily stand up still worth it? Does it provide enough value for the team over and above that value currently being sucked from rich communication throughout the day anyway? It seems to be that the only people who might benefit from the standup, then, are the chickens, who really don’t listen to what we’re saying as they don’t understand it and are just there to wait until the end when they get a chance to say their piece.

Usually, not particularly interesting or worthy.

None-the-less, the stand up does provide a moment of the day at which you can see everyone’s trousers and shoes and feel like a “team”, a group of people all striving for the same goal and not a disparate set of developers hunkered behind a screen waiting for the end of the day.So, then, is the standup merely an ideal? Something that is important only for what it IS and not what it does or provides in the way of value? Perhaps, but I don’t mind either way, either options provides some benefit and some is better than none. Also, I like to look at shoes.

I recently started a conversation on the agile development group over at Yahoo Groups. My initial question was, should I ditch the product backlog? We tend to do a lot of just-in-time development, the requirements come in, sometimes mere hours before our sprint planning and as such, these stories are only on the product backlog for a very short period of time, if at all. Often they’ll just come in via email from the Technical Director and they get added to the sprint. The backlog, then, becomes ever growing and it seems that some of the stories on there will never be looked at again, let alone completed. It’s the fable of the ever-growing backlog.

So, do we even need it? Jack Milunksy of Agile Buddy fame said, if you’re not using it, then in pure lean fashion, ditch it and stick with the just in time. Others have said, if you’re not using a product backlog, how will you define a release strategy or be able to roadmap the product? Which is a good point. The answer then is that it depends. Why is this always the answer with anything scrum?

If you’re using the product backlog as a place to store and prioritise stories, use as a release manager or roadmapper, then you should keep at it. If you’re using the product backlog as somewhere to store half-formed ideas of possible features of additions to your product, then maybe you should use a backlog. If you get your priorities minutes before the sprint starts, hastily written on the back of a beer mat, then maybe not. Or, maybe just use it to store high priority stories that are definitely going to be worked on but not yet.Above and beyond all this though, is grooming. If you don’t groom your product backlog, then you’re in a whole world of pain. Epics, which are at the bottom will suddenly become top priority and, without grooming, will still be Epics. Your team may even throw things at you, I wouldn’t be surprised. So groom the backlog regularly, get the team involved and make sure you’re breaking stuff down!

Update: Jack Milunksy over at the Agile Buddy blog even blogged about this: http://blog.agilebuddy.com/2009/11/do-you-even-need-a-product-backlog.html

‘”Doing Scrum” is as meaningless (and impossible) as creating an instance of an abstract class.’
- Tobias Mayer

This is a quote from Tobias Mayer, a certified scrum trainer. I had an opportunity to today to describe exactly what this means. I was accused of using the quote as “anti-scrum” and I think that opinion is so wide of the mark, it’s almost firing backwards.

If you’re actively trying to “do scrum” in your workplace, then I think that you’re missing the point about scrum itself. Scrum is just a framework, a tool you use to help you achieve your goals and the goals of the business for which you excercise your talent and skills. Don’t waste time on trying to “do scrum” – you’re either doing it or not. It’s a simple set of rules that are bolted on top of the agile manifesto.

Even if you’re not doing “scrum”, but you’re doing “scrum-but” (ie: “We do scrum, but …” – thanks Jimi Fosdick!), then don’t sweat it. If you’re delivering potentially shippable software at the end of every sprint, then you’re on track. With any luck (and a bit of judgment and guidance from your Scrum Master) you’ll start to stick closer to the rules as you inspect and adapt and begin to adopt the manifesto through the medium of retrospectives.

It’s all about not breaking the rules. No one wants to play games with people who break the rules, it means there’s nothing tangible, no edges or borders, no boundaries with which to keep the game flowing.

As Tobias says, Scrum is about surfacing organizational dysfunction, instead of bending the rules

Read the entire article entitled, Scrum Doesn’t Do Anything here.

Some people are like Yay! others are Boo! Me? I’m more meh…

I can understand both sides and, frankly, can’t get behind either. Some say that the CSM course isn’t about learning how to do scrum, but learning how to take scrum to your business. That’s fine. These people, they say “Why do you need a certificate for something that you can prove you know by doing?” Well, you need to find somewhere to do it first, surely? Being a CSM makes it much easier to get a job as a scrum master, and, once you’ve got that foot in the door, you can then start to prove yourself as a CSM by actually doing. Fair enough right?

Others, they say; “OK, so what’s the point in the certificate in the first place?” and I say, well, I concede that point also. Going on the CSM course is enough, as long as you can say you were on the CSM course – how do you do that? With your automatic entry to the Scrum Alliance, you can looked up on the register.

Well, I say meh… If it helps you get a job, then great! If it helps you get a foot in the door, then great. If it helps you pay attention more in the training, then that’s awesome too. Just don’t worry to much about it. At the end of the day, it’s what you DO in the day to day of running your sprints that counts.

Besides, the industry is full of certificates and exams that mean exactly squat. It’s just like university – you prove you can learn and retain enough knowledge to pass a test; although it’s a hell of a lot cheaper!

How many times do you or your team work with the product owner to groom the backlog? Once or twice a sprint? Once a month? Less? How about trying to do it every other day, or even every day?

Grooming the product backlog is one of the most important things you can do in scrum (besides following the rules and um, delivering). It helps you maintain a healthy outlook on what you’ve got to do, it helps you recognise and deal with dependencies and blockers earlier and it goes a long way toward release planning and estimating a project delivery date (or date range, more likely).

Also, if you groom the backlog daily, it’ll take much less time and be a much less arduous task. I’ve done both. Sitting with the product owner once a week to groom a backlog of many, many stories is a pain in the arse. The most appropriate time is just after the stand-up. You’re all standing around the sprint/product backlog, so take the time to ask for a couple of volunteers to spend 15 minutes examining some stories, grab the product owner as well. I always suggest that anything bigger than a five pointer is probably a good candidate for breaking down a bit further or defining acceptance criteria and anything bigger than a 13 should definitely be broken down further.

Take a big or ill-defined story and ask, can this be broken down? Can we break this into any smaller parts that offer business value? If so, then great, break it up there and then, if not, then ask if it can be broken into smaller parts that don’t provide business value? Sometimes, this is a worthwhile questions as, when you break a story into smaller, non-valuable parts, inherent value sometimes bubbles to the surface, taken out of context, the team might spot a way that smaller stories that don’t deliver value, might actually do so after all.

Then ask the team if the acceptance criteria is accurate enough, does it, in their opinion, describe the “done” state of the story? Obviously, the only party who can actually say when it’s really “done done” is the business, but your team will always have a good idea of what “done” is to them and the product owner should be able to offer more information on what the “done” state is.

Finally, see if you can ascertain some kind of rough priority order, this is especially relevant for technical stories that may not provide value for the business at large, but will often support other stories that do provide value and you should always try and pay off your technical debt wherever possible.

So, if you groom the backlog with the product owner and various members of your team more regularly than you do now, when you get to sprint planning, it’ll be a breeze. You’ll spend much less time discussing what the stories mean than the actual tasks needed to complete them. You’ll know exactly which supporting technical stories you may need and, if you’ve been aggressive at breaking down stories to two, three of five story points, you’ll be able to be fairly accurate with your commitment.

And really, that’s what it’s all about, being slightly more accurate, so the confidence of your team is high that you can complete what you’ve committed too. Your team will love you for making sprint planning less like pulling teeth and your product owner will love you for delivering what you’ve committed to.

Win-Win as they say.

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.