Burndown chart vs Burndown mentality

It's no surprise that scrum projects are using Burndown chart for tracking sprint progress and overall product release too.

Burndown chart, as name suggest, keeps burning task/stories as and shows what is still left out.
Every day after, stamp up meeting, is good time spot when we re-draw this chart to reflect previous day's work.

Here is the trap which I have seen many team fall in very easily. While we are using daily stand up to come up with burn DOWN chart, what we are really talking about is how much amount of task have been done (i.e. 4 hours or 1 story point etc). Now truly speaking that information is not really helpful to us. In Agile there is no look back. Whatever happened, does happened. No one in the world can go back and change them. What is important is what to do next. What I mean to say, is we need to start talking in terms of what is left in order to finish this story.

Now, does that sounds like weird argument? One might argue that, isn't that the same information. After all we know total size of the story and by telling what has been done, we can easily figure out what is left. (That's simple math I learned, way back in primary school).

Here is my answer,
My experience with past and present scrum project has taught me the above simple math of deducting completed point from original size is failing too often. While working on story we might encounter more or less complexity than originally anticipated. Which means, for then encountered simple story what is left is too less or for then encountered complex story what is left is much more. And somehow human minds are evolved in such a way that they can give more accurate answer for what is left vs how much is done.

Personally, our charts have improved a lot (in terms of reflating actual picture) when we started forcing team thinking in terms of "what is left" pattern over "what is done".

I call this pattern "BURN DOWN MENTALITY" to update burndown chart.

Thought? comments? arguments? I would love to hear.

Develop smartly :)

Paradigm shift from Unified Process to Scrum

Till now, we all were talking about Unified Process and how well it fits into process driven software development. After all its all about following those stringent processes very strickly and rest is just done for you. These are the process which puts your organization at the status were you can claim to repeat your success every single time.

Hey but wait a minute... Aren't we really lieing to our self? Almost after decade of process driven cycles, and those big big claims of being process dependent aren't we really really depends upon one or more individual's skill to make it happen. After all if its process driven than why not to stop employeeing people and let your so called process does the job.

Todays fact is ; we do depends upon people, not process, to make our project a success. Scrum is all people and getting agile. It focuses more on Individual and Interaction over processes and running software over comprehensive documentation. To scrum responding to change is more important than negotiating for contracts.

So how does it work? Pretty simple... it follows KISS protocol..
K I S S = Keep It Simple Stupid

Ever heard customer comment, something like "Hey, your software is great but not what I wanted it to be"?. Well, this is more of a common than exception when we work on the assumption that customer knows everything. In reality Customers are not very decisive at the very begining of the project and this is fair enough since they don't have any ground yet base on which they can make solid (non-volatile) decisions.

Scrum is meant to handle this situation. Here team works in small iteration called SPRINT (typically 2-4 weeks). It all starts by a meeting called Sprint planning (typically 1 day) and the product owner, stack holders and team; all together find out what needs to be done over next 2-4 week and how to verify that its done (Acceptance criteria). Once this is done, team starts working on implementing those features (User Sotries in scrum methodology) which are required in current sprint cycle. Last day of the sprint is sprint demo, where one of the team member demostrates all the features. and the cycle repeats for the next sprint

The obvious advantage here is stack holders have base to make there next decision based on which they can rectify or mold the direction of the project rather than waiting till the end.

watch this space.....more on scrum and how it works.. sometime later.. :)