When you place focus on how quickly you can get functionality done, and have the ability to measure just that, then the estimates don’t much matter. In fact, many using a Kanban approach have simply stopped estimating at all. Yes story sizes vary, but being able to give a wait time plus or minus a few days is sufficient for many organizations’ concerns.
Some do still estimate stories. Then use those estimates in conjunction with cycle time. Using a spreadsheet we can calculate the average cycle time for stories with a given estimate. If you do this, consider placing a handy chart next to your Kanban board showing estimate in one column, and wait times in adjacent columns. With this you’re answering the real question stakeholders are asking for when they get estimates: “when am I going to see this functionality in the software?”
If your stakeholders are like mine, they don’t want to know when they’re going to get this functionality, the want to know when they’re going to get all this functionality. I find that if I place stories into a spreadsheet with start and end dates, and calculate cycle time, if I select an arbitrary time period — say a two or three week time period — I can see how many stories where completed during this time period. For instance I might see the team finished 22 stories in 3 weeks — that’s about 7.3 stories per week. Given a backlog of 100 stories I can reasonably infer that it’ll take between 13 and 14 weeks (100/7.3). That’s yesterday’s weather for Kanban — at least the way I calculate it.
If I know that during three week time period there where 15 working days and that 5 developers worked the entire time, that’s 75 developer days. Knowing that lets me calculate the average number of developer days per story: 3.4 (75/22) — Which is darn close to pi — which makes me believe it has to be right. ;-) This number, 3.4, is what XP practitioners referred to as load factor.
During the weekend Hill and I had a good chunk of time to talk about my health, and options. We are both currently leaning hard away from doing anything at all.
I know I’ve just said a mouthful.
We’re not trying to make a decision as much as we’re trying to let one emerge. As we think through the reality of the possible paths it’s hard to imagine signing up willingly for the misery of treatment in the face of lousy odds. I have a lot to say about this. I don’t quite have it well enough gathered in my head to write it down at the moment.
[Not doing is thought of as harder than doing. It would appear to not always be the case.]
“Such thoughts are like burrs stuck to my pant leg, prickling me once every few strides,” he wrote. “It’s not until I get out onto the open prairie, or into canyon country, or under a ceiling of stars that I’m finally able to shake them off. There is a wild joy that swells in my chest. Every day there is a new trial. There’s something new to learn; something new to see with every step, every turn, every drop into a canyon labyrinth. It’s an infusion of newness. And when immersed in this constant newness — when every step is exploratory, every interaction, novel, and every day completely different from the previous — it’s hard to think of going back again to the dullness of the normal, the expected, the planned.”
[This is why Noah is so happy when we hike. A constant infusion of newness.]
Source: Half Past Done