Aug 27

In SCRUM we put sizes on user stories that translate into velocity points. This is used for all sorts of things but primarily to determine how much work there is to do and how much has been done.

I've seen plenty of discourse over whether or not stories should be sized based on complexity or the amount of effort the team estimates will be required.

This is a fruitless debate and is a distraction from the goal of Agile SCRUM. Debating this is not useful.

Instead I suggest that effort and complexity really is the same thing. User stories should be sized based on how much work there is to do to get it done because that is what the velocity is supposed to measure.

More complex items take more effort. Items that require more effort are inherently more complex as the odds of something unknown cropping up are increased.

So the question is not of complexity vs. effort- Just realize complexity = effort.

Tags: |
Aug 13

In Agile SCRUM we size things to put an estimate of the effort and complexity involved in producing the work product. We might say that the size of something is extra-small, small, medium, large, etc. These sizes translate into velocity points. How many of these points we complete each sprint tells our product owner how much work he should expect to get done in a release. It is one of the most visible measurements of productivity that will be seen by upper management.

In my teams, the primary things that are sized are user stories and defects. User stories represent new work and defects represent work to fix a defect in the application. I have found that they way teams tend to do their sizing is different for user stories and defects. It is like a different scale is used.

In general a medium sized defect winds up taking a lot less work than a medium sized user story.

This creates an issue when measuring velocity and ultimately when measuring productivity. If your team spends a much larger percentage of time working on defects in one release than in the next, you will see a drop in velocity.

As we know velocity is watched by many folks in any organization. Perceived drops in velocity will raise questions and cause concern. It should! However, in this case what is seen as a drop in velocity really isn't. It is simply an issue with how sizing is being done.

I am now pushing my teams hard to consider sizes of defects in context of user stories that are also sized the same. 

It is very important for a scrum team to size work efforts consistently. Always push the team to compare the work effort of an item they are sizing to other items they have sized in the past- Especially when sizing defects. If you don't then your velocity metric will be misleading.

Tags: | |