I already wrote how overjoyed I was about using SCRUM, and the joy and the enthusiasm just keeps growing. After a few iterations on my latest (Srum-runned project), I’ve discovered a few things different than my previous work methods.

• importance on putting a value on features
• breaking down “complicated” features to more simple ones
• the obvious scope increase after some “clarifications”

Putting a value on features

All features are not all as hard and as complicated as others, some are easier, and other are harder. Some are “unknown”, and other known, so estimations are practically impossible to define unless we break up all tasks to simple features. So burnup/burndown charts of finished features finally make sense. Usually if the tasks are listed and progress is shown in a burnup/burndown chart, the actual work done and work remaining on the chart have nothing to do with the actual progress, usually due to “not clarified” or “misunderstood” client requests and features that have not yet been started.

Breaking down complicated features to more simple ones

I’ve read a “rule” for estimations is never to estimate anything as a single task if the estimate is longer than 2 days. I absolutely agree with this. I’ve seen features estimated to take 20 days or 50 days. I consider this estimations to be lazy and risky, and this is often done to the lack of specifications or clear client requests. Cure for this would be to (even if you do not have clear client requests or specifications) write the list of features as you understood, estimate them and offer that those features will “cost” that many days/points/money. This brings another issue to this whole story.

Obvious scope increase after “clarifications”

Sure, I could misunderstand the client request, or specification, but I did promise to finish the estimated tasks in that period at that price, and if that’s wrong, it’s my problem, but if the scope increases after “clarifications”, it should be a normal thing to:

• increase the period in which the final product will be finished
• increase the price
• if this clarified feature must be finished in the current iteration, the client can:
• select a feature (weighing same amount of points) that will be excluded from this iteration
• understand that it cannot be done, finally understanding the importance of clear specifications we’re all talking about

Finally, clients are not stupid or disrespectful of our work as we often feel. Working with SCRUM has helped me demystify the whole request/specification/estimate/development process. Earning me reduced pressure, more respect and trust from the client, and more pleasure in working on the project for both of us.