Quick.
When you think of estimating and planning techniques in Scrum, what method do you think of first?
Wait.
“There is an official way Scrum says you *must* do estimating and planning,” you may be thinking.
You’d be incorrect.
And.
Thats OK.
See, there is nothing in Scrum that says you have to use any certain technique for estimating and planning.
My recommendation though:
DO SOMETHING.
People will continue arguing about the different techniques for-e-v-e-rrrrrrrrrrrrrrrrrrrrrrrrrrrr.
So what.
If you have something that works today, use it.
If you do not have a clue about how to do estimation and planning, or think:
“Hey we are using Scrum and we do not need to tell the customer when we are going to finish….”
Um… try telling your customer that. Let me know how that goes, because I can pretty much guarantee that answer will not invoke any confidence in your delivery as a team.
Remember, your customer does not care about story points or gummy bears or peanuts or t-shirt sizes or dart boards or ouiga boards or whatever.
Ask the customer what they really care about.
THE answer to that question may rock your universe.
So.
What kind of estimation and planning techniques are you using today?
What works?
What fails?
Please feel free to discuss these and other answers about this topic in the comments of this thread.
Phew.
See.
I did something today for YOU.
Instead of estimating and planning on when this next cartoon strip would get to you… I just did it.
THAT is why people are reading this (you are my customer as someone who reads this blog, and I thank you for that!).
PS –> Yeah, I am coming out of a long term slumber from publishing cartoons on this site (for instance, THIS cartoon has been sitting and yelling at me for over a year to GET STARTED again already. Stop planning on, “The next day…”). Man, talk about analysis paralysis. I was there with this site. For those that are new here, welcome! For those who have been with me for years, let me say an incredibly humble, “Thank you” for sticking with me. Help me keep these coming to you — if you have ideas (I still have soooooo many) or want to contribute in any way, please contact me and let’s chat. There are some changes coming to the site, and I’ll let you in on that news shortly. All good.
Hi all.
The chat test today during the two hour-long sessions was a success.
I learned many things, and, as all things we do with Scrum the next iteration will be even better.
I can go into the retrospective we had — but suffice it to say that there were enough in the “cons” section (versus “pro”) for trying another tool.
So.
From 13:00 – 14:00 EST (GMT-4), Friday, June 12, 2009, we will test a new page (it is located at www.implementingscrum.com/chat). And a new chat system. Feel free to go in and take a look at it ahead of time; however, I will plan on being there for an hour in the afternoon to discuss a Product Backlog for the ImplementingScrum site.
As a stakeholder, I’d really appreciate like your input.
Tony is back from a short vacation and we will have yet another comic strip out early next week.
And.
I’ll make an announcement on Friday night that will put another service “live” on this site. And yes, as usual, it is still all free. I do love what I do for a living, and thank all my clients (and future clients) for the work I get so that I can give back to the community through initiatives like this site, www.implementingscrum.com.
And hey… if you are not following me on Twitter yet… do so on the right side of the screen in the sidebar. It is 2009 and there is so much GREAT stuff on that system about agile and scrum. Stuff you should not miss! Including real-time announcements that I do not make via the blog entry or e-mail (it is usually THAT time sensitive!).
I hope to see you online to discuss the Product Backlog for the site at 13:00 EST (GMT-4) at the following address: www.implementingscrum.com/chat.
Thank you.
- mike vizdos
Hi all,
Today is our first try at a new format (in addition to the cartoons) at www.implementingscrum.com.
It is called, “ImplementingScrum – UnScripted” and will feature audio and/or video in different formats along the way. By the time this goes out, it should be out on youtube and here is a link to the “.mov” format (uses quicktime and is just under 17MB — for some reason this is MUCH clearer — any recommendations???).
Using FeedBurner, it should also find it’s way out to iTunes as a podcast… let’s see together how it all works and continue to inspect and adapt.
Fair? (smile)
This first version of this is with a guy “Down Under” who had some spectacular patience with me this morning (in addition to the fifteen hour time difference!).
His name is James Brett and he maintains a site at www.scrummaster.com.au and recently (with a LOT of help with the people there!) published a survey, where you can see the results at www.scrummaster.com.au/Article.mvc/Detail/43 or download the PDF file from www.scrummaster.com.au/Content/download/ScrumSurveyResultsJan09.pdf.
The video of this is about eight minutes long and goes into the survey a bit and introduces the topic. It is not meant to be exhaustive — right now it is a test of the technology convergence(s) and as usual we want to keep these things short and to the point.
A few other references made in the video included a retrospective formats article and retrospective why.
You can also check out a few cartoons about retropectives on this site (there is a three part series here:
www.implementingscrum.com/2007/09/04/scary-team-retrospectives-part-one/
www.implementingscrum.com/2007/09/10/retrospectives-not-just-reading-a-book-part-two/
www.implementingscrum.com/2007/09/17/walk-into-the-light-retrospectives-part-3-of-3/
As usual, any errors anywhere on the video or my site — I accept that responsibility.
Take a look at the video and the links above for the survey and other stuff and PLEASE comment about it below.
Inspect and Adapt.
Let’s see where we go.
As usual!
Thank you.
www.implementingscrum.com
www.michaelvizdos.com
Welcome back to a new week and first cartoon of 2009 at www.implementingscrum.com.
Thank you for continuing to follow and spread the word about this blog and our cartoons.
Get ready for a blast this coming year.
The last cartoon of 2008 covered the topic of how to handle questions from outside stakeholders during a Scrum (or iteration).
Remember that even familiar chickens can be dangerous to derailing an iteration.
Eek.
Does that sound too dogmatic?
Hmmm.
Let’s think.
Who calls an iteration “Done?”
That would be the Product Owner (look back at this old comic strip from the early days for a refresher on that).
And, the “old way” of doing this — in a waterfall environment — was to bow to the pressure. That leads to very funny cult-movies; however, in reality it sucks for everyone involved.
Especially if you bow to it while using Scrum.
So.
If you are a Team Member on a Scrum team and you get asked to do something that is outside the Sprint Backlog, you’ve GOTTA turn it over to the Product Owner to deal with.
So, this comic strip shows that.
Our intrepid character Pig did the right thing.
And.
What is the Product Owner now supposed to do with this information?
This is not a blame game.
But.
Someone needs to be responsible for the decisions.
How does this sit with you?
And where does the ScrumMaster play in this situation?
Comments, as usual, are requested and will help guide where we take this in the future (smile).
Thank you,
- mike vizdos
www.michaelvizdos.com
www.implementingscrum.com
Welcome back to a new week and new cartoon at www.implementingscrum.com.
For new subscriber via email, facebook, and twitter — Welcome and thanks for the interest in the site.
Please feel free to pass this site on to your friends and talk about it on twitter and other social networking sites.
The problem depicted in this cartoon is something I see a LOT when working with teams around the world.
Even when Scrum is being implemented on teams within an organization.
Hmmm.
So what do we do about this situation?
When asked for a status from a Chicken within a Sprint, Scrum talks about the team members not saying, “No” and punting it to the Product Owner.
The same goes for a new feature request.
In the past… before Scrum… this type of request was a major cause of never getting to “Done.”
This is the main reason to have a strong demarcation point between the Product Backlog and the Sprint Backlog. The main reason is to help shield the team from the outside “Noise”.
Care to share some real life stories about this via comments below?
How do you do this without committing career suicide?
Who really is responsible for telling outside Chickens to speak with the Product Owner?
What does the Product Owner need to do with this next?
Is this really an important concept or what do you think about it?
Please share with us…
Thank you,
- mike vizdos
Older Articles »
