Friday, July 6, 2012

Agile costing

A friend of mine +Nicholas Vanderpyle and ex-coworker was asking questions about agile costing. I thought I'd give it a try to answer him:

Anyone do agile costing in their software projects? I was in a meeting that segued into a discussion about how to cost and whether to adjust the cost or create a new ticket when new effort is discovered.
I'd love to pick your brain offline about how you do agile planning and costing. It'd be nice to see how someone else does this.

This is my "basics" answer. They are probably a lot more variables to take into account, but this is what comes to mind right away:

Simplify costing.

* Use the fibonacci sequence. 1, 2, 3, 5, 8. Anything greater than 8 is probably too big to be a single story. Break it down to 2 or more.

* Only cost things that add business value. Bugs do not add business value, they should have never happened in the first place, that's why we use testing (unit/automated/regression)

* "Research stories" are that, research. Do not cost them, they do not add business value. They will add value once we implement them. Even better, research stories should not be "stories" but "chores" or "internal dev tasks" or whatever name suits your process.

* To avoid never-ending discussions when costing stories, assign someone as the "master of ceremonies." That person's job will be drive the session, moderate discussions, set a time limit for the session (or discussion), and have the final word on costing if no consensus is reached.

That's all I can think of at the moment.

Few recommended readings:
* How to Estimate effort
* A case for costing bugs
* A case for not costing bugs
* How to split user stories

Hope this helps!


No comments: