Velocity Points

Replies to This Discussion

Permalink Reply by Manish Manekar on April 13, 2010 at 17:18

Dominic,

It happenes with most, if not all! There are many ways teams handle it and here is my take on such a situation:

1. Every task - planned or not, this way or other - should be accounted for.
2. It obviously adds up to the sprint backlog and is negotiated - in agreement with the product owner - to be addressed in the current sprint or in the future. This may result in story split and/or rescheduling this or some other story to another sprint.
3. Retrospect - lesson learned! Improve estimates from now on by giving each story thourough consideration.

Hope this helps, keep up the good work!

Manish.

• ▶ Reply

Permalink Reply by Dominic Hurst on May 13, 2010 at 11:42

Hi, thanks for the reply. I deal with this situation in a similar way to what you described above, thanks again

• ▶ Reply

Permalink Reply by Ilja Preuß on May 5, 2010 at 14:10

First and foremost, if you don't know the answer, be a rolemodel and admit it. Being able to admit when you don't know something is a strength and necessary behavior for a team, that as a leader you probably want to model for them.

Regarding your question: the burn chart doesn't actually show how much you have burned. It shows how much there still is to be burned. So, yes, a burn chart actually can go upwards, which just would show your reality. Transparency is the point here, as far as I can tell.

• ▶ Reply

Permalink Reply by Dominic Hurst on May 13, 2010 at 11:41

thanks for the reply. I generally add a negative burndown underneath the original to track the points added during the sprint and then redraw the sprint burn line, hope you get what I mean. Similar to your chart going upwards but it keeps going down. I was joking about the not telling them bit I do practice transparency.

Thanks again was just wondering if anybody did it differently

• ▶ Reply

Permalink Reply by Ilja Preuß on May 16, 2010 at 17:55

I've heard of people doing that on the release burn down when new work gets added by the PO. Not convinced that it's such a great idea for a sprint burn chart. But then, I'm not a big fan of sprint burn charts or tracking stories, anyway...

• ▶ Reply

Permalink Reply by Radha Israni on May 6, 2010 at 17:57

1) For the remaining tasks within the current Sprint - have a mid sprint meeting and re-assign story points to the remaining tasks- this will likely cause you to miss out on certain tasks but at least you will have better and more accurate reporting which inevitably sets management expectations

2) Build up a list of take away lessons that you can use for your next sprint- e.g. maybe you designed tasks at a macro level which is why you could not properly assess complexity? if so you might want to break down your tasks further in the next sprint(the way I do task design in Spring planning is to identify tasks that need to be done in each tier like web, middleware, database, and so on- helps me better plan and track the overall task and avoids over or underestimating story complexity.

• ▶ Reply

Permalink Reply by Dominic Hurst on May 13, 2010 at 11:42

thanks for the reply

• ▶ Reply

Permalink Reply by Kelly Waters on June 6, 2010 at 9:00

Hi Dominic. Actually I suggest you deal with this common situation differently.

First of all, if it's additional scope (more features), the team should estimate the points, decide with the Product Owner whether or not it needs to go in this Sprint, and if so, you should negotiate what falls out of the Sprint to make way for it.

If, on the other hand, it's unplanned tasks required to complete the planned scope, you should add the tasks to the board so they can be seen and tracked, but I would suggest that you should never change the estimated points that you had originally set for the user story.

The beauty of Velocity is that statistically it compensates for bad estimating. The consequences of unplanned tasks - e.g. a user story being estimated at 3 points and turning out more like a 13 in reality - is that the team still only scores 3 points for it. The consequence of this is that the team's Velocity is lower than expected, meaning that the team plans future Sprints based on a more realistic target, with the team's actual Velocity being based on what they had thought when the user stories were estimated.

Some user stories will of course be quicker than expected and others will take longer. Statistically, over the course of a few Sprints, this averages out and the team's Velocity becomes a reliable measure of how much the team can really deliver in one Sprint. The team's commitment is then based on the historic reliability of their estimating, not based on what they think they can do which, in my experience, is often wrong.

I agree this issue should be discussed in the team's Retrospective. Even though you shouldn't change the estimated points part-way through the Sprint, it's still helpful to understand why it took longer, as this is obviously a good learning opportunity for the team.

Kelly.

• ▶ Reply

Permalink Reply by Phlip on June 6, 2010 at 17:57

How many days in a "sprint"?

Scrum makes the mistake of setting a 30 day sprint. That's good for the business output side, but bad for developers. We need to produce a steady stream of bite-sized changes in functionality, so developer iterations should be 1 week. With daily deployment - such as to a manual testing community.

At that resolution, schedule slips are less likely, and less likely to go unnoticed. "But that was supposed to be easy!"

• ▶ Reply

Permalink Reply by Kelly Waters on June 7, 2010 at 9:03

I see your point Phlip, but the meetings in Scrum make one-week Sprints quite onerous. Personally I like 2 week Sprints...

Kelly.

• ▶ Reply

Permalink Reply by Phlip on June 7, 2010 at 13:52

Point. XP Classic is two-week. Ambitious coaches like Industrial Logic set that to 1 week.

• ▶ Reply