AGILE IN ACTION

Tag: estimation

Monday, August 9, 2010

If you're estimating, know why you're estimating

Posted by Simon Baker
Estimates are lies and estimating is waste. That doesn't necessarily mean it can't sometimes be useful. It's still waste but used at appropriate times, in appropriate ways, and understanding the flaws in the results it can help things along with business and finance people and clients. People just have to realize that it's just not possible to be any good at estimation. The best you can hope for, and certainly what you should aim for if you have to do it, is consistency rather than accuracy. If you're always consistently over or consistently under that's enough for reasonable planning.
Read more...

Thursday, May 14, 2009

Pomodoro galore

Posted by Simon Baker
Almost everything for us is now a pomodoro. Some time ago we replaced the per-iteration planning game with on-demand planning pomodoros and the end-of-iteration retrospective with a pomodoro retrospective.
Read more... Comments: 7

Wednesday, January 30, 2008

Playing with stuff

Posted by Simon Baker
For the last 8 weeks we've been using Jeff Patton's techniques for using goals and user stories in the product backlog to express activities, tasks the user performs and tools the user needs to perform the tasks.
Read more...

Sunday, October 7, 2007

Treat estimates as solution budget

Posted by Simon Baker
Jeff Patton gives us some good advice about how we view our estimates:
Read more...

Monday, July 30, 2007

Planning poker

Posted by Simon Baker
Via InfoQ . Nils Haugen explains planning poker and how it works. At XP Day in 2006, I attended Nils' session Experiments in Agile Estimation .

Sunday, December 3, 2006

XPDAY2006: Experiments in Agile Estimation

Posted by Simon Baker
Read more... Comments: 1

Friday, December 9, 2005

Under-promising and over-delivering is a process smell

Posted by Simon Baker
A short while ago I read a post by Skip Angel that talked about delivering on your promises. It reminded me of a situation a colleague told me about where a scrum team was under-promising and not telling the product owner, so that they had a better chance of delivering or over-delivering. I described the situation on the Scrum Development newsgroup.
Read more...

Tuesday, October 4, 2005

Track remaining effort in hours not days

Posted by Simon Baker
I have always tracked the remaining effort to complete an engineering task in ideal hours rather than ideal days. However, the current project I'm working on is using real days as the unit. The switch back to real time from ideal time is consistent with Kent Beck's latest approach to estimation. Regardless of whether ideal or real time is used, I prefer tracking the remaining effort in hours and not days.
Read more...

Thursday, July 14, 2005

Agile estimating and planning

Posted by Simon Baker
Agile estimating and planning techniques are a combined subject that holds particular interest for me. Over time, I've experimented with various techniques and some worked better than others. Estimation is always a lot of 'fun'! How many times do project managers, stakeholders, indeed whole corporations expect estimations to be accurate within a negligible tolerance? Too often. Worse still, they hold you to the original estimates even when they've been empirically modified. But planning is where I see it all go wrong too often, and sadly usually from the outset. Whether it be as simple as not employing adaptive planning techniques where plans consequently take root and become inflexible and pointless, or more subtly because of the way the problem domain or user stories are disaggregated to produce an emerging design with low cohesion and tight coupling.
Read more...

Wednesday, November 10, 2004

Story points and ideal time

Posted by Simon Baker
A common misconception by teams is that there is a hard and fast relationship between story points and ideal time. They might devise a rule that says 1 story point = 8 ideal hours, which allows them to conclude that a story estimated at 3 story points will disaggregate into engineering tasks totaling 24 ideal hours.
Read more...