Agile Lab - Training, Coaching and Consultancy

Friday, 15 October 2010

How to Count Unfinished Stories for Velocity

First, let me point out that I'm generally in favor of an all-or-nothing stance toward counting velocity: if a story is done (coded, tested, and accepted by the product owner), the team earns all the points, but if anything on the story isn't done, they earn nothing. At the end of an iteration, this is the easiest case to assess: If everything is done, they get all the points; if anything is missing, they get no points. If the team is likely to take on the remaining portion of the story in the next iteration, this works well. Their velocity in the first iteration is a bit lower than expected because they got no credit for partially completing a story. In the second iteration, however, their velocity will be higher than expected because they'll get all of the points, even though some work had been completed prior to the start of the iteration_ This works well as long as everyone remembers that we're mostly interested in the team's average velocity over time, not in whether velocity jumped up or down in a given iteration.

Posted via email from What Stringer's Reading

Wednesday, 13 October 2010

Velocity in a Nutshell

Suppose a team estimates a project to include 200 points of work. They initially believe they will be able to complete twenty-five points per iteration, which means they will finish in eight iterations. However, once the project begins, their observed velocity is only twenty.  Without re-estimating any work they will have correctly identified that the project will take ten iterations rather than eight.

Posted via email from What Stringer's Reading

Tuesday, 12 October 2010

Ten Unmyths of Project Estimation

Saturday, 9 October 2010

Estimates vs Commitments

"Many organisations confuse estimates with commitments.  As soon as a team expresses an estimate, they are forced to commit to it."

Posted via email from What Stringer's Reading

Dealing with Uncertainty

"The best way of dealing with uncertainty is to iterate."

Posted via email from What Stringer's Reading

Past Performance...

When someone is late on the first of a handful of similar items we've all heard or given the answer, "Yes, I was late this time, but I'll make it up on the rest." This stems from the belief that the knowledge gained from completing the first activity will allow the remaining similar activities to be completed more quickly than called for in the plan.  The real knowledge we should gain in a situation like this is that when an activity takes longer than planned, all similar activities are also likely to take longer than planned. [my italics]

Posted via email from What Stringer's Reading

A Good Plan

A good plan is one that is sufficiently reliable that it can be used as the basis for making decisions about the product and the project.

Posted via email from What Stringer's Reading

Planning the wrong product

The most critical risk facing most projects is the risk of developing the wrong product.  Yet this risk is entirely ignored on most projects.  An Agile approach to planning can dramatically reduce (and ideally eliminate) this risk.

Posted via email from What Stringer's Reading

Size vs Duration

Being Agile

in reality, you are Agile, Extreme or otherwise when you know enough about the practices to adapt them to the reality of your own specific situation.  Continuous learning and adaptation are core to Agile development.

Jim Highsmith, foreword to Mike Cohn - Agile Estimation and Planning 

Posted via email from What Stringer's Reading

Uncertainty

Many planners don't understand a key concept - you can't "plan away" uncertainty.

Posted via email from What Stringer's Reading

Flexibility vs Plans

flexibility to adapt to changing business conditions and absolute conformance to original plans are incompatible objectives.

Posted via email from What Stringer's Reading

Untitled

I've gone into too many organisations where making outlandish early commitments,and then failing to meet those commitments, was acceptable, while those who tried to be realistic (and understanding uncertainty) were branded as "not getting with the program," or "not being team players." In these companies failure to deliver seems to be acceptable, whereas failure to commit (even to outlandish objectives) is unacceptable.

Mike Cohn - Agile Estimation and Planning

Posted via email from What Stringer's Reading

Untitled

the difference between a good (enough) plan and a great plan probably isn't worth the effort.

Mike Cohn - Agile Estimation and Planning

Posted via email from What Stringer's Reading