< Back

Agile Estimation - The East Agile Way

0

Posted by Anonymous on 04 Nov 2010 at 06:19

Agile Estimation Of Iterations

 

If you haven’t done so already, take a moment to read the blog on Reliable Estimates Using Agile.

Mike CohnIn this blog, I will talk about the actual process of estimating an iteration and specifically how we do it at East Agile. I had the chance to take a class with Mike Cohn (right) and he is really good at explaining the estimation process. His book on estimation can be found on Amazon.

Estimating against a project that hasn’t been accepted (bidding, ROI analysis, etc.) is left for another blog.

Agile Estimation

Before You Start

Once again, lets make sure that you have everything you need to start estimation. So:

  • You are a member of the team.

  • You know your availability and all your team members availability.

  • You’ve studied and understand the definition of done for the project.

  • You have user stories clearly defined by the Product Owner.

If any of this is missing, then you probably aren’t following the agile rules and need to take a step back before estimation.

Iteration

An iteration is a period of time that work is done. Typical durations range from 1 week to 1 month. At East Agile, our iterations are short: 1 week. So, in the iteration planning meeting, we are estimating what User Stories we will complete in 1 week.

Commitment

Keep in mind what was covered about Agile Estimation and Reliability. You, as a team, are committing to the User Stories you say you will complete in the iteration. The User Stories you commit to end up on the Current Log (see Pivotal Tracker for more information on current logs).

This isn’t a “we think it is possible that...” but a “we can assure that we can deliver what we promise by the end of the iteration”. This is why it is so important that your estimates are reliable. Of course, you as a team can always decide to work overtime to complete your commitments but that isn’t part of the Agile process.

Agile does have an out: you can alter your commitment by asking the product owner if you can remove (or even add to) the User Stores you have committed to. However, this is like the team stopping in the middle of a play in football and asking the coach if they can back off on their commitment to winning and try for a tie instead.
 

Iteration Planning - Where You Estimate

Estimation and commitment is done in the iteration planning meeting (in Scrum, called the Sprint Planning Meeting. As I noted before, we did not create this great agile process. We just use it without the branding).

The next section contains the Agile Rules for Iteration Planning at East Agile. We use the word Call instead of a meeting because because our Product owners are not usually physically at our sites and we use conference calls, Skype, and even chat to achieve the outcome of a physical meeting.

Iteration Planning Call

A time boxed call (2 hours (5% * 40 hours) involving product owner, team and stake holders (optional but can’t talk) and domain experts (optional: Available to answer questions). The purpose is to estimate out and commit to the next iteration of work by clarifying the user stories with the product owner and estimating them while the product owner listens in.

Sometime Before the Call

  • Product Owner - Prunes the backlog and the ice box. Orders user stories by importance (which stories provide the most business value right now) in the backlog.

  • Agile Master – Prepares the backlog and ice box if the product owner was unable to do so.

  • Team – Quickly reviews backlog and prepares questions.

During the call

First half (Time-boxed 1 hour)

In the first half of the call:

  • Product Owner reads stories to the team and explains their vision.

  • Team takes notes and asks questions of the Product Owner and/or domain experts brought by Product Owner. Stories should be broken into smaller stories if needed.

Second half (Time-boxed 1 hour)

In the second half of the call:

  • Select the first user story from the Backlog.

  • Estimate the user story (East Agile uses estimation poker: see see http://www.planningpoker.com/detail.html).

  • Place the story on the Current log (Pivotal tracker may do this automatically for you).

  • Continue the estimation process until the team has filled up one iteration of work.

  • The Team commits to their estimate. Work begins immediately after the iteration planning call.

  • Estimate the next 4 points of work in the backlog so that there is something for the team to do if they complete their current commitment.

Highly Recommended Rules and Notes:

  • The Product Owner and Agile master are available to facilitate, when asked for help, but cannot interrupt the team's planning process.

  • During estimation, the Product Owners can decide they don’t want a story anymore.

  • The Team will need to find time, during the iteration, to fill up the current log if they were unable to do so during the time-boxed call.

Iteration Planning Call Partially-Explained

Just listing our rules isn’t going to help you understand why we follow these rules. The rules themselves are based on best known agile practices.

For example, the idea of a time box. This is an Agile concept that forces meetings to have a time limit. As soon as the meeting hits the time limit it stops (the job of the Agile master). This encourages people to stay on point.

So, the iteration planning meeting is limited to 2 hours at East Agile (the general rule is 5% of the iteration length) and, as the rules show, if you can’t get the planning done in that time, you will have to make time to do it later in the project.

Most of the other rules (like the Product Owner must prepare the product backlog before the meeting) will be explained in other blogs.

Conclusion

At East Agile, we use Agile Estimation processes in conjunction with Pivotal Tracker (www.pivotaltracker.com) to assure reliable and useful estimates. Useful estimates are provided in a fully transparent manner allowing the Product Owner to make educated guesses on the ROI East Agile is providing in the current iteration.  

Pivotal Tracker enables this process by implementing an Icebox, Backlog, Current, and Done log (queue) and manages the communications between developers and business owners over the course of an iteration. Pivotal Tracker was developed by Pivotal Labs to support agile software development. The application is free for everyone to use and is widely used by a large number of leading online services and software firms. Rob Mee
Rob Mee

CEO, Pivotal Labs

It is through these proven Agile processes that we are able to commit to and deliver products on time through weekly iterations.

Pivotal Tracker

 Screen Shot: Pivotal Tracker

 

0 comments
Leave a comment