Kanban development oversimplified: a simple explanation of how Kanban adds to the ever-growing Agile toolkit:

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.