Ham And Eggs

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.

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.

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!