Nothing else in Scrum generates more confusion than story points. So what are they and just as importantly, what are they not? Here is my definition:
Story points represent the relative difficulty in completing development tasks that produce business value
When working on a complicated product it can be tempting to focus on individual components rather than on end-user functionality. For example, a team might decide to build out an authentication component first before adding a user interface (UI).
The disadvantages of this approach include:
I have a long-running debate with a friend of mine about the state of software development.
I argue that by applying agile best practice the majority of software projects can be successful. My friend counters this argument by saying the trouble is that nobody ever applies agile best practice, so software projects continue to fail.
In many ways my friend is right, in the real world agile is often badly applied. The reason why this is has puzzled me for many years.
Even if I don't know how to implement something I can almost always write a test for it and If I can't figure out how to write a test for it I have no business programming it in the first place. - Kent Beck
Many processes in agile are mutually supporting. A good example of this is testing and its relationship to the development iteration.
I'm a great believer in getting quality in as early as possible in the development cycle. Checks that run automatically in an IDE are best (for example the Checkstyle/PMD plug-ins in Eclipse).
But these have one drawback: they are not enforced.
Nothing kills the productivity of a development team more than working on and supporting poor quality legacy code.
You start work in a new team, full of grand ideas and determined to do things the right way. Then you discover the morass of existing software that is sitting at the heart of the system. This code has been around for years. Nobody likes it, everyone wants to get rid of it. But that would mean spending lots of time and resource and producing little, if any, business value.
In my career I have seen the transition in popularity from FORTRAN to Pascal, from Pascal to C, from C to C++ and from C++ to Java. That is not to mention the introduction of Hibernate, Spring and numerous other technologies.
Why would you want to spend time and effort to adopt agile?
That's a good question and one that should be asked and answered by your organisation before you attempt an agile transformation. First you need to define what you want to gain (or recognise a problem that you want to overcome). Then you need to agree how you will measure progress to ensure you are actually achieving what you set out to do.
What is agile? A simple question with a complicated answer.
A good point of reference for agile is the agile manifesto. This consists of four basic premises and twelve more detailed principles.
Agile is an approach to software development that is aimed at minimising the cost of making changes. Think of agility as the capability to make rapid changes of direction, to be flexible and to adapt.
