I have received many requests to assist with Agile training and deployment. I am humbled by your interest and, being a huge proponent of Agile, want to help any way I can by providing consulting where I am able to.
New Found Respect for Story Points
I gotta tell you, I have been using Story Points with teams for quite some time now. But recently, working with onboarding more than 9 teams at one company in the space of 3 months, I have learned to appreciate what Story Points really mean and the effect that they have on making teams successful.
With each new team that is getting up to speed with Scrum, the hardest transition is figuring out how to estimate in Story Points. There are many ways to help teams do this, including starting them off with 1 story point = 1 ideal day. But that's not the purpose of this blog post.
What is amazing is that with each of the 9 teams I have onboarded recently, each one consistently missed completing the planned Story Points in the first Sprint quite significantly.
In each instance, during the retrospective, I was asked...
"But we're so close to completing the Stories, can't we get most or some of the points?!"
While I am not such a radical must-follow-every-Scrum-rule-by-the-book kind of person, when it comes to Story Points, I am quite adament. You don't finish the story, you don't get any points!!! Period!
So my question to the team after that discussion is: "What could you have done to finish some of the stories?" Well, the answer to that question becomes quite obvious, and all the lights go on. The team could help swarm the top priority stories (minimize the work in progress). I have covered this before..."stop starting and start finishing" is the name of the game.
In each case, after the 3rd sprint, the teams were in the groove and the Story Points started to go up on the board.
Adopting such a hardline approach helps teams to really learn the meaning of DONE and, in my opinion, using hours couldn't get you this effect even if you tried.
Additionally, I have found that teams are quite optimistic to start out. So they typically sign up for too much work in the first one or two Sprints. This all helps to setup much more realistic plans and gets teams to a stable optimal velocity sooner.
Hope this helps.
Jack
What does 'onboarding' mean? Is it like waterboarding?
Posted by: Andy Rubio | 03/25/2011 at 04:15 AM
+1 for waterboarding. No points for "trying?"
Posted by: Agile Scout | 03/25/2011 at 08:18 AM
+1 for waterboarding. No points for "trying?"
Posted by: Agile Scout | 03/25/2011 at 08:18 AM
+1 for waterboarding. No points for "trying?"
Posted by: Agile Scout | 03/25/2011 at 08:18 AM
Jack,
Previous posts of your blog have been spammed full.
Do you have anti-spamming stuff in place? Can I suggest a captcha like recaptcha?
I'm not taking the time to examine your code for a hidden input field that should remain empty ;-)
Bye
Jan
Posted by: Jan Doggen | 05/19/2011 at 04:14 AM
My views on project documentation specific to closure are listed at http://architecture-soa-bpm-eai.blogspot.com/2011/06/are-we-still-living-in-waterfall-era.html
Posted by: Tushar | 06/15/2011 at 08:42 AM
Thank you for leaving great review. Looking forward for your further update.
Posted by: Cheap insurance rates | 07/14/2011 at 07:12 AM
Thanks for quality information. But software testing is the best way to protect yourself from unexpected expenses.
Posted by: Validation Testing | 07/18/2011 at 12:48 AM
Thanks a lot for sharing with useful review.
Posted by: Microsoft application development | 08/02/2011 at 02:45 AM
Your insights could not have been more emphatically instructive.
Posted by: Itaz Document | 12/07/2011 at 05:07 AM
Thank you for making great evaluation. Excited for your further bring up to date.
Posted by: Print Stickers | 01/25/2012 at 01:07 AM