Resourcing, it’s just an estimate OK?
by MikePearce on Mar.05, 2010, under Estimating/Planning, Scrum
Reign of the Supermen by fengschwing
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.
An Open Letter To Those Modifying Scrum To “Fit”
by MikePearce on Feb.19, 2010, under Scrum, ceremonies
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
Is my time more valuable than your time?
by MikePearce on Jan.12, 2010, under Uncategorized
A Warlock
As anyone who has ever done sprint planning will tell you; estimating the time a task will take to complete can sometimes be a risky, confusing and sometimes arrogant or embarassing business.
Unless you have absolute equilibrium in your team, ie everyone is at the same level and can perform at the same pace, you’ll often come across situations where a developer will say:
“That will take 3 ideal hours!” and sit, smug in the knowledge that they can do that task in 8 hours (or more, generally. Don’t forget Boyle’s law).
“Um, ” says a small voice, “I think it would take 6 hours.” The new team member, green as the grass on the other side, but sharp as a tack pipes up. “I don’t know how to attach the hoo-hah to the wot-not, I’d need to research that.”
“It’s easy!” says smug developer, “You simply wangle the wand at the warlock and insert the key of truth.”
“OK, ” retorts the green guy, “Didn’t I read in the out-of-date wiki entry that there is three factor authentication on the key of truth? I’d need to read up on that before I started the task.”
“Pah”, says smug developer, “Then I should do it.”
and thus fails scrum. Allocating tasks during planning is, sometimes, a neccessary evil, especially if you’re up against an arbitrary deadline as we often are. However, if you do find yourself having the luxury of being able to swarm on stories, or pick any task from the board, then you should and you should usually pick one you have no idea how to do. This’ll give you a chance to do some on-the-job learning from your peers and mentors. Consider this though:
“It’ll take me six hours, but I’ll have it done by the end of the day tomorrow, ” says green developer, “I don’t have any other responsibilities at the moment”.
“Ah, yes, ” says old man smug, “I am the scrum master (yes, yes, quiet down – sometimes you DO need to do both) and I need to the new business team with some issues and also I have to record some training screen casts, so I won’t be able to have it done for another three days, even if I started it now!”
So, as you can see, it’s all swings and round abouts. The rules (or guidelines) I’ve heard many times state to go for the higher figure. With a dash of common sense obviously, if it’s more than double the amount of the lowest figure, then you’ve got other problems. Always err on the side of caution I say, but that’s up to you.
Why is this important? You need to be consistent with the blocks of time/effort/whatever you estimate with. Ideal hours seems the best way to go about it, but don’t, whatever you do, start referring to six ideal hours as a “day” it’ll just confuse the issue. Six ideal hours is just that. It might take one day, or it might take six. However long it takes in real time, make sure your estimates in ideal times are as accurate as they can be. It’ll help in the long run as you’ll get better at estimating, better it getting it right sprint after sprint and it’ll help you eliminate the waste. Time holes that suck away your resourced hours will be highlighted because by the end of the sprint, you’ll not have “spent” the ideal hours, yet you’ve pissed away a two week iteration. But at least it will show you where your problems lie.
Does the daily standup provide value?
by MikePearce on Dec.18, 2009, under Scrum, Uncategorized, ceremonies
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.
Estimate like you mean it
by MikePearce on Nov.11, 2009, under Estimating/Planning, Product Backlog
- Poker Check from Photos
Scrum says that planning poker should be short, snappy, time boxed and fairly rough. The more ambiguous the stories, the higher the number on the Fibonacci scale. This is great, it allows you to discuss the story at some length, make sure you’re all on the same page and then throw up a number.
What if your team doesn’t understand every aspect of the project? If you’re new to scrum, or you’ve got silo’d ’specialists’ for different segments of your product or company (and, honestly, who hasn’t?), or you’ve got a new team member, perhaps a new hire, or someone from another team altogether, then planning poker might not be the most productive hour of your week. You might need to spend time during planning discussing what the story is, how the section of the product or application works and why. That’s going to eat into your timebox for discussing the actual story. So, how do you get round the fact your team isn’t all fully aware of the entire application, or even, in some cases, the part of the application your team is assigned to?
You could just go for it anyway, you might get lucky and everyone estimates the same anyway, your velocity may change, perhaps, but it’d stabalise in the end. Or you could run some workshops to get the new team members or those unfamiliar up to speed with the product, but that eats into your sprint time.
Or, you could send out the story ahead of time and let the team members spend some time pondering it before poker. Email or print and drop on each persons desk a list of the stories (which should be well defined and adhere to the I.N.V.E.S.T acronym) and let the team spend some time getting a feel for them. Those that are most familiar with the project can scan through to see if there’s anything out of the ordinary and those less familiar can spend a little time asking other members of the team, or even getting acquainted with the code. Up close and personal like. That way, when you come to planning, your timeboxes could, if you wanted, be that much shorter and your estimating should be more accurate, making the entire process a bit more solid. As more accurate estimates lead to confidence in committing to stories, lead to delivering what was committed to, leads to sticking to a release plan, leads to the team being full of WINN!Of course, this does all assume that your stories are well defined…
Should you bother with a product backlog?
by MikePearce on Nov.10, 2009, under Lean, Product Backlog, Scrum
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
Anti Agile? Moi? I think not!
by MikePearce on Oct.29, 2009, under CST, Scrum
‘”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.
IS EVERYONE AWAKE?
by MikePearce on Oct.27, 2009, under Uncategorized
Try this in your standup tomorrow;
Wait until it’s your turn to offer yesterday/today/blockers, the make something up. See if anyone notices. If they do, then you appear to be doing scrum properly as your team are interested in what you have to say. If no-one bats an eyelid, then you’ve got a problem. The standup is an information radiator, some way of telling your team and anyone else who is interested, exactly what it is you’re doing. If what you’re doing is dull, then spice it up a bit. If it’s the same thing as you were doing yesterday and probably the same thing as you’re doing tomorrow, then try and be a bit more detailed – what EXACTLY did you do.
If people are genuinely not interested, then perhaps you’ve structured your team wrong. Really, you should all be working round the same kind of area, so if people aren’t interested because it’s not something they do, or will do, then it sounds like you may not be swarming and your developers are siloed. If that’s the case, then shake things up, because you’re not doing scrum!
CSM Certificate
by MikePearce on Oct.26, 2009, under CSM, Scrum
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!
Grooming a product backlog
by MikePearce on Oct.25, 2009, under Product Backlog, Scrum
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.
