Agile Story Estimating

Thanks Wade!

It is amazing how much "waste" goes away when we don't worry about sizing anymore!

Kiron

"3. Story points and velocity are for the team and the team only. They help the PO prioritize, helps the team think through the work, creates a point of conversation when points aren't aligned, and helps the team plan work at a sustainable pace. Defend this. The moment management reviews your story points, the points will become meaningless, because your team will have to start gaming the system (remember that points are relative). "

If you are a project sponsor or project director you must decide how much money to allocate to the project or to one of its phases. Obviously there is no accurate way of estimating the needed budget but still you must base your decision on some estimates no matter how accurate they are.

If the story points are only for the team and management should not be allowed to use them then how can the sponsor/director estimate the needed budget???

It is virtually impossible to stop management from using the story points. If you don't provide them the points, so that they can convert to days, then you must find an alternative way of estimating the time needed to complete the project (or one of its phases) so you can provide this information to them.

Some years ago I worked as a developer on a project that was using Scrum. The User Stories were all written from the beginning so the velocity was known from the beginning. If we were dropping bellow the set velocity we were considered a low performing team. That was a nightmare and I am sure many developers have such horrible experiences with working "Agile".

You can't stop management from using the Scrum estimates and metrics as they need them but when they do use them it can end up a nightmare for the workers especially for those that are doing the actual work.

If your management was monitoring team story points and the team lived in fear of lagging velocity, then your team was not working in a safe environment and I would bet money that the organization was not agile. You can't micromanage your teams and claim any high degree of agility. You don't get empowered teams, you get minions.

What you've described is common, though, and that's why I guard my teams' velocity closely. It's an internal metric for them to aid in planning and calculate estimates. As soon as managers turn it into a performance metric, it becomes meaningless. The team living in fear has only to inflate their story points to increase their velocity. Now your team has delayed the executioner, but your product owner cannot effectively estimate delivery. Management isn't assisting the product team in this scenario, they're destroying it.

Rather than share my team's velocity, the PO should use some of the common tools (like burn charts, for example) to set expectations. Yes, a competent stakeholder or customer can easily deduce average velocity from a burn chart, but that's a much different scenario than having an authoritarian manager beating down a team based on some nonsense iteration performance metric. An organization that insists on such a thing either doesn't understand the iterative and complex nature of the work they've undertaken, or else they're using buzzword terms like "agile" and "story" to disguise the authoritarian work culture they've established.

Thank you for your explanation Andrew. However Management would always want time estimation so you must figure out a way to provide such estimates.

If you don't convert points to time then you must use the velocity to determine how much time would it take to complete the project or part of it. Then if the velocity drops management would get excited.

In waterfall projects there is not much stress to keep the velocity up as velocity does not exist. Some say than by using Agile/Scrum you can't hide and must be transparent but in reality is just more pressure and additional stress on the working team members. For the PO and especially for the SM is not that much stress as they are not the ones having to deliver the work.

Andrew -

you miss my point with regards to mature teams not needing to size any more. If all stories are small enough, then why size anymore? The focus can then be on how many stories (all of roughly the same size/smallness) we can complete within a fixed amount of time.

Kiron