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: | |
Jul 26

Sprint demonstrations are important for more than just the development team. They are the opportunity for clients and client representatives to provide early feedback on what is being developed. It is an opportunity to get a first look at the new functionality so that when it is released you are not seeing it for the first time.

Attending sprint demonstrations is a valuable use of your time. Anyone who uses an application or supports clients using an application should attend sprint demonstrations whenever possible.

Attending a sprint demonstration should be something that is done actively. It is your opportunity to raise questions, issues, make suggestions and provide your input on how things being added to the application should function. It is your opportunity to give input on how things that you need to use and support work.

Use this opportunity to help make the applications you work with better, easier to use, and easier to support.

How a sprint demonstration is handled varies but the key value is to get real feedback on what is being built. Anything that helps deliver this value is reasonable to consider doing. Feel free to suggest changes to the demo meeting format that would help make this value more real.

Please- attend sprint demonstrations whenever possible and be part of making things work better.

Tags: | |
Jun 24

Agile is all the buzz in the development community. SCRUM is one of the most popular forms for agile software development. There are plenty of would be gurus ready to help you implement Agile SCRUM and plenty of books to go along with it. Agile SCRUM promises to help you push out better software, faster, and at a controlled cost.

So can Agile SCRUM deliver on its promises?

I've been doing Agile SCRUM for about 2 years now and the best answer I can give to that question is yes; as long as you understand what Agile SCRUM really does. Following Agile SCRUM will not solve your problems by itself even if you think you're following it to the letter. It will not replace good development practices and solid architecture. It will not make up for inadequate quality control or badly designed applications.

What it will do is help shine the light on issues. There will be pain involved in going to an Agile SCRUM world. If you manage the transition the promise is real, but the challenges are many.

Going forward...

Going forward on this topic I will discuss many of the challenges I have seen and overcome. I will also discuss the challenges I am currently dealing with and my attempts to solve them.