Tag Archives: estimating

June 25, 2012

Release Dates in Agile, Not Taboo

By Stephanie Davis

I’ve heard a lot lately about how it’s not-so-Agile to set release dates for major features, epics, and projects.  Some are uncomfortable being given a date (mainly teams) and others are uncomfortable without a date in hand (mainly, Product Owners, executives, and stakeholders).

This very much a myth to be dispelled.  Dates do not go away with Agile!  Rather, it is how we predict and communicate dates that should change.

With Agile, release dates are fixed based on time-boxed iterations.  In our case, we tend to release after every sprint, so there is always a release date every two weeks.  Therefore, by nature of time-boxing, the schedule is a fixed constraint.  With the schedule being a fixed constraint (as is cost based on team size), it is scope that remains flexible.  So, the scope that is included in any given release is flexible based on what the team was able to accomplish, what stories get dropped, what natural disaster impeded the team, who was out sick, and so on and so forth.  Whether that scope accomplished is acceptable for release to production is always a Product Owner decision.

Second, what’s critical to understand is that in Agile we PREDICT.  We predict dates for major features, epics, and projects.  In fact, everything we do in Scrum is in support of us all getting better and better at predicting or being predictable rather … Capacity, story points, velocity, release planning, etc. Furthermore, the closer you get to any given date, the better you are at predicting it and the greater the confidence too.

With that understanding, how we communicate dates needs to be adapted for our Agile world.  First, we should modify our language.  Rather than say “Project X will be released on 7/1” let’s say “Project X is predicted to release on 7/1 and the team has an 80% confidence in that date”. Second, we should always remember that with schedule and cost as fixed constraints, scope is flexible. So, we might say “Project X 1.0 with A and B features is predicted to release on 7/1 and the team has an 80% confidence in that date”.

With some education around this topic we will all be better able to talk dates without the taboo of it not being Agile.

1 Comment   |  tags: , , , | posted in Uncategorized

February 24, 2012

Story Points: What’s The Point?

By Stephanie Davis

So, what’s the point of Story Points?  9 Scrum teams and 8 sprints into our Agile transformation and it seems that some still struggle with the proper use of Story Points, a common relative estimating technique.  That said, I put together the following tips on this topic to help my teams (hopefully they will be of help to your teams as well).

  1. Story points are a relative measure of effort to done, NOT complexity, NOT priority, NOT sequence.  Something that is highly complex might take very little effort to complete and might be considered 1 or 2 or 3 story points. On the other hand, a 13 point story might be worth further decomposing into smaller, independent stories.
  2. A common technique for story points is the use of the famous Fibonacci sequence of 0 1 2 3 5 8 13, 0 being hardly any effort and 13 being the most effort.  Commit it to memory! Say it frontwards, backwards, forwards until you make it a habit.  Or, make a game of it and get some Planning Poker cards for your teams.
  3. Story points must always be established before tasks and task hours.  You can do them as part of backlog grooming, at the start of your sprint planning, or even negotiate them over e-mail, but never-ever do tasks and task hours before you establish story points.  If you do, you basically negate the benefit of your relative estimating technique.
  4. After establishing story points for stories within a given sprint, you should be able to group all the 13’s and the 8’s and the 5’s and so on and they be of relatively the same effort.  Make a point of thinking about it that way during your Sprint Planning.  Furthermore, you can use the task hours you come up with in Sprint Planning to make sure it all jives.  If you have a 13 point story and a 3 point story and both have just 6 hours of tasks then it is questionable as to whether you got the story points right or if you’ve considered all tasks.
  5. Story points are determined by the Team (based on all that has to be accomplished to meet your definition of done).  It’s not about just analysis or just QA or just coding.  The ScrumMaster and the Product Owner do not determine story points.
  6. There is indeed such thing as a zero point story if it’s something that the team has relatively no effort for.

The point of Story Points is to someday stop having to think about all those tedious task hours.  If you know your team’s velocity of story points over time, you can use story points to determine what can nicely fit within a sprint.  For instance, I know that some of my teams at full capacity are 40-ish story point teams.  With that knowledge, the Product Owner can select 40-ish points of stories for the team to work on in any given sprint.

1 Comment   |  tags: , , , | posted in Uncategorized