Posts Tagged ‘product backlog’

h1

Agile Heresy

January 2, 2012

 Those who do the work are the best people to estimate what it takes to perform the work.  Makes sense.  Sounds reasonable.  The problem with such a definitive statement is the subjective word “best”.  Most of us read “best qualified” into that statement.  But what if the “best” person to do the estimation, won’t?  Have you ever worked with people on an agile team who don’t want to contribute to the backlog item estimation activity?  Sometimes a rigid corporate culture causes people who are, or perceive themselves to be “lower on the food chain” to say little and thereby avoid perceived conflict or anger of a more senior person.  Sometimes it’s a cultural behavior.  Sometimes fear.  Sometimes shyness.

 One successful team that I coached found a workable solution.  They selected a small sub-team from the more senior people on the team.  This sub-team did the estimation for the whole team.  It worked well and they have been very successful.

 But do you think this is agile heresy?  If so, how would you otherwise fix such a situation?

 Paraphrasing that old adage: You can lead a horse to water, but you can’t make him estimate.

Advertisements
h1

Burndown Bingo – An Agile Anti-Pattern

November 6, 2011

Your newly minted global agile team is dutifully performing the rituals typical of agile development.  They do their morning scrum, they update their remaining task hours, review their burndown chart, and so forth every day.  The end of the sprint comes, they deliver successfully, and during the retrospective the business praises them highly for how their actual burndown tracks closely with the ideal trend line on the burndown chart.  The team is happy.

The next sprint is going along well but mid-sprint the business looks at the burndown and notices the actuals are not tracking so closely anymore (not wildly off course, just noticeably more than the last sprint).  At the next standup the business raises mild alarm at the deviation and wants to know why, why?  Now the team is not so happy.  One of the distributed teams appears very concerned about the displeasure expressed by the customer.

As the next sprint is planned, the product backlog item estimates from the distributed team seem unusually uniform and unrealistically high.  The hours estimated for their sprint tasks are “healthy” also.  Amazingly, during the sprint the actuals now track EXACTLY with the ideal trend line.  Not close – exact.

Hmmmm.  Could just be random luck and serendipity.  Could be an error in the burndown calculations.  Or could it be that the worried, distributed team (who are the last chronologically to update their hours) has enough “padding” in their estimates that after the other teams update their hours, the worried team updates their remaining hours so precisely that – BINGO! – the actuals precisely match the projection,  every day.  Naaah!  Couldn’t be. …………. Could it?

Ever seen such an anomaly on your projects?