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 :)
Showing posts with label Agile. Show all posts
Showing posts with label Agile. Show all posts
Tuesday, July 29, 2008
Monday, July 14, 2008
Agile Planning - Planning on wall
Till last week we were facing serious issue with respect to our sprint planning. Team is new to Agile and except me, everybody else is working on agile project for the first time.
Time was killer factor for our planning session. Almost every single time, we are running out of time and it ends up being 1.5 day planning session for 2 week sprint. (Again Business is also responsible for this mess as those user stories were half cooked meal and there wasn't any acceptance criteria)
Last week whole picture changed when we were successful in convincing business, that its important to have user story ready well before planning session. We used their own weapon against them and warned them without well defined user stories, the software is at risk and we will never be able to release it on time :)
That worked magically!
Business spent 2 days, organizing their thought, collected input from other concerned people and finally provided us well defined user stories which has clearly written acceptance criteria.
Wow... we entered greenland for the first time on the project.
Next was our turn and this time business wanted us to estimate them such that they call get idea on when can they release the product.
Looking at our history of planning this would have taken us, probably 4-5 days, if we would have continued to follow our old practice.
But we didn't had that much time. So it was necessity that became mother of new discovery, again.
Earlier when we used to estimate each story, we all where breaking it into task(This was sprint planning, against tasks and not release planning against user stories). And then discuss scope and complexity and come up with magic figure against each task. The whole operation was single threaded as everybody was on same task card and again getting conses for magic figure was taking time too.
So this time, we thought of using multi-threading for planning. And hence one of the wall of our Ping pong house, became playground for this planning. Every body in the team had 4x6 sticky note and a pen in their hand, No body seats in the room and then we have one person read story. (This guy was really proxy for business for us) Then starts Q&A session till we get all answers. Meanwhile everybody in the team uses their sticky and start writting all possible task that they can think of and stick on the wall. Sooner (less than 2 min) we have 10-12 task hanging on wall. They we just look at the cards and eliminate dubplicates. Task keeps on comming till everybody in the team, can't think of anything new.
Then starts next step, re-arrange task into logical order, either vertical or horrizontal.
Next and final step, was to give number to each of them. That starts with top most card, and any one call out number, others either agrees or give different number and then we uses Fist-to-Five to get agreement. Game is everybody vote for the number for given task, by raising either 1-5 figures. Number of figures means, different things as follow
1: Go to hell, I can't get this at all
2: I seriously doubt
3: Well may be good, I am Ok with that
4: Sounds good to me
5: totally agree
3 onwards is fine and you can accept that number for the card. However if even single 1s or 2s means call for further discussion and then second round with new figure based on that discussion.
Well, that's all. The whole thing worked dam good. Room was filled with lot of energy as against two or three sleeping members in the chair. Everybody contributed and we had our planning doen in one and half day without any overtime. We even had two 15 min break and one hour lunch break in between.
Above all, it was team's estimate. We created it together and we owned it. This has bought automatic buy-in from all members. Whole team was happy and everybody in the team had high degree of confidence in the estimation.
The whole magic worked!!!!!!!!!!!!!!!!!!!
I called it 1+1 > 2
Any thoughts, comments, queries, arguments??? I will be glad to hear.
Also how do you go for sprint planning?
Time was killer factor for our planning session. Almost every single time, we are running out of time and it ends up being 1.5 day planning session for 2 week sprint. (Again Business is also responsible for this mess as those user stories were half cooked meal and there wasn't any acceptance criteria)
Last week whole picture changed when we were successful in convincing business, that its important to have user story ready well before planning session. We used their own weapon against them and warned them without well defined user stories, the software is at risk and we will never be able to release it on time :)
That worked magically!
Business spent 2 days, organizing their thought, collected input from other concerned people and finally provided us well defined user stories which has clearly written acceptance criteria.
Wow... we entered greenland for the first time on the project.
Next was our turn and this time business wanted us to estimate them such that they call get idea on when can they release the product.
Looking at our history of planning this would have taken us, probably 4-5 days, if we would have continued to follow our old practice.
But we didn't had that much time. So it was necessity that became mother of new discovery, again.
Earlier when we used to estimate each story, we all where breaking it into task(This was sprint planning, against tasks and not release planning against user stories). And then discuss scope and complexity and come up with magic figure against each task. The whole operation was single threaded as everybody was on same task card and again getting conses for magic figure was taking time too.
So this time, we thought of using multi-threading for planning. And hence one of the wall of our Ping pong house, became playground for this planning. Every body in the team had 4x6 sticky note and a pen in their hand, No body seats in the room and then we have one person read story. (This guy was really proxy for business for us) Then starts Q&A session till we get all answers. Meanwhile everybody in the team uses their sticky and start writting all possible task that they can think of and stick on the wall. Sooner (less than 2 min) we have 10-12 task hanging on wall. They we just look at the cards and eliminate dubplicates. Task keeps on comming till everybody in the team, can't think of anything new.
Then starts next step, re-arrange task into logical order, either vertical or horrizontal.
Next and final step, was to give number to each of them. That starts with top most card, and any one call out number, others either agrees or give different number and then we uses Fist-to-Five to get agreement. Game is everybody vote for the number for given task, by raising either 1-5 figures. Number of figures means, different things as follow
1: Go to hell, I can't get this at all
2: I seriously doubt
3: Well may be good, I am Ok with that
4: Sounds good to me
5: totally agree
3 onwards is fine and you can accept that number for the card. However if even single 1s or 2s means call for further discussion and then second round with new figure based on that discussion.
Well, that's all. The whole thing worked dam good. Room was filled with lot of energy as against two or three sleeping members in the chair. Everybody contributed and we had our planning doen in one and half day without any overtime. We even had two 15 min break and one hour lunch break in between.
Above all, it was team's estimate. We created it together and we owned it. This has bought automatic buy-in from all members. Whole team was happy and everybody in the team had high degree of confidence in the estimation.
The whole magic worked!!!!!!!!!!!!!!!!!!!
I called it 1+1 > 2
Any thoughts, comments, queries, arguments??? I will be glad to hear.
Also how do you go for sprint planning?
Friday, May 4, 2007
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.. :)
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.. :)
Subscribe to:
Posts (Atom)
