Let's Talk Dev

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.

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.

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.