Category: story points

Planning poker - the real epiphany

March 27, 2009 by Jack Milunsky

Intro
Last week I established three good reasons to go with Story Points and why they're so popular. This week I want to talk about one more important aspect of story points and then provide tips on how to get started estimating in Story Points. I find this is a rather big challenge for teams just learning the ropes.

Lets talk
Scrum is a learning framework. It's been designed specifically with Inspect and Adapt points with a very specific purpose. Because estimating is a cross-functional team activity estimating the backlog is just another opportunity for the team to get together to discuss the task at hand, for the stakeholder or product owner to explain what is expected of the team. This discussion is a great way to build team morale, synchronize expectations and getting everyone singing to the same tune. Because Scrum projects are agile, it’s important that teams engage in discussion to ensure the team stays on the right track. And because the estimation is done in a team setting the estimate is generally more accurate as it represents a cross functional view of the task size, not just the developer view.

The significance of Story points

March 20, 2009 by Jack Milunsky

Expecting your teams to estimate in Story Points can be quite a leap of faith. When I first introduced the concept of Story Points at my previous company no-one could wrap their heads around the concept. When it comes to estimating, we’re so accustomed to thinking in days or hours that making the leap to some obscure, seemingly illogical measurement is quite the expectation – especially a bunch of engineers.

Getting used to it
Once you start using Story Points, it usually only takes a couple of sprints before teams start to understand the magic in this new practice.

Accounting for bugs the agile way - part II

March 6, 2009 by Jack Milunsky

Last weeks post struck a cord with readers and as a result I got some really good feedback. Based on the responses I decided to use this week's spot to clarify my position on some of the issues as I see them.

I believe that ...

1. Teams should do whatever they can to fix bugs that are found during the sprint in which they're found. The definition of "Done" means the feature is coded to standards, unit tested, functionally tested, documented and all known bugs are resolved during the sprint. If you postpone bugs, what seems trivial at first will mean significant build up of technical debt which you will need to pay for downstream.

How We Actually do it: Accounting for Bugs in an Agile World

February 27, 2009 by Jack Milunsky

Today I'd like to share with you a really important aspect of Agile software development - how to account for bugs in your daily plans.

I am frequently asked by teams I consult with how to deal with bugs if you're Agile and using Scrum. Questions like the following come up time and time again:

"Should I track hours burned fixing bugs?"
"Should the hours burned on fixing bugs count toward my Story Point velocity?"
"When do you schedule bugs and should this be done during Sprint planning?"

You Need to Account For Bugs

My company is often working on many simultaneous projects and having to juggle resources. To get everything done on time and bug free requires careful planning. As a result we have to ensure that we're considering all aspects of software development including bug fixing. Bottom line is Bugs take time to fix and so you have to account for them. If you don't, you will have an inaccurate measure of your teams productivity - something that will definitely lead to poor planning and late deliveries. (....read more)

Velocity: Measuring and Planning an Agile Project

December 10, 2007 by Jeremy Weiskotten

Bridgekeeper: “What is the velocity of an unladen swallow?”
King Arthur: “An African or European swallow?”
Bridgekeeper: “Huh? I don’t know that…”

- Monty Python and the Holy Grail

One of the most important metrics of an Agile team is its velocity. (No, you don't have to give the receptionist a stopwatch and do laps around your office.) In project management terms, velocity is the amount of work that a team can complete in a specified period of time.