Great stuff...
----
Scrum is really simple, barely a process, more a framework. The hard work in using Scrum is fixing the things that it exposes, actually inspecting the things that it makes transparent and adapting to optimize the results and the organization that produces the results.
Scrum is not the organization that produces the results, or the amalgam of procedures, tools, automation, and standards that are implemented as a result of the inspection, as part of the adaptation. Scrum is the very simple mechanism that helps an organization be more effective in accomplishing its goals.
I've been following the threads about type N, A, B, C and advanced Scrum. Although these may represent the engineering, personnel, and product management practices that an organization adopts as a result of Scrum's inspect and adapt, they aren't Scrum. I think we are mistaking the consequences of Scrum with Scrum itself.
What may be most destructive about these supposed extensions is that they will divert people from the real work of Scrum ... seeing what is going on in their organization and going through the change process to become effective. And learning how to continually inspect and adapt to keep their organization's practices optimal. Instead, people may think that all of these things that use the Scrum name are advances in Scrum, templates that they can mimic and then, amazingly, they are advanced development organizations, also.
We are running the danger of any small process. People want to make it bigger. Well, Scrum isn't bigger. Each organization's total ability to build complex products is certainly bigger, and hopefully continually evolving, but it isn't Scrum.
Keep Scrum Simple.
Ken
Tuesday, March 28, 2006
Sunday, March 26, 2006
Hours vs. Story Points
In my talk, I briefly described User Stories and Story Points. I could have easily spoken for an hour on User Stories, but I could only spend a few minutes. To highlight, User Stories are:
One of the key values of User Stories is that they can be estimated. Estimations are made using "Story Points". Story Points are a relative measure of feature difficulty/complexity that are useful for planning. If one feature takes twice as much effort as another, it will have twice the story points. As it turns out, Story Points are a more accurate measure of project velocity and release schedule than using hours and days.
"Hours and days" attempt to not only estimate the effort of a feature, but also the velocity of the people working on it. With Agile Planning, we separate those two measures. We estimate the effort of the feature in isolation and emperically measure the velocity of a team that is doing the work. There are many benefits of doing this. They are separate numbers that come from separate factors!
One major benefit of estimating stories is using the "poker game". The poker game is where the team and customers get together and discuss the stories. Each story is discussed and then each person at the meeting raises a card that shows how many story points they feel should be assigned to the story. The first vote usually shows a wide variation of points. We then discuss the estimates (usually the high & low voting people talk first). This is very beneficial because the unknowns and assumptions are revealed. People take very different views of a feature and this leads to wide variations of expectancies when the feature is estimated. All of this comes out in the discussion of the story being estimated and some of the points make it in as "conditions of satisfaction" for the story.
This process is repeated until the room is pretty close on what the points should be and then we move on.
To estimate an entire release (4 months) of stories took a dozen people an entire day (we had to go offsite so we wouldn't be interrupted). We also have "lookahead" planning sessions where the entire team gets together about once a month to refine the stories (disaggregate larger stories into smaller ones) and estimate those stories.
The end benefit is that teams get a consistent story burndown velocity that allows them to see how well they are tracking their release goals (measured once every 2-week sprint). This is the velocity of real feature development that is far more valuable than estimated hours.
- Feature descriptions from anyone on the team or any customer.
- Use a simple template to insure correct communication.
- Have "Conditions of Satisfaction" which are things that can be seen or tested in the review.
- Are estimated.
- Are not dependent on other stories.
One of the key values of User Stories is that they can be estimated. Estimations are made using "Story Points". Story Points are a relative measure of feature difficulty/complexity that are useful for planning. If one feature takes twice as much effort as another, it will have twice the story points. As it turns out, Story Points are a more accurate measure of project velocity and release schedule than using hours and days.
"Hours and days" attempt to not only estimate the effort of a feature, but also the velocity of the people working on it. With Agile Planning, we separate those two measures. We estimate the effort of the feature in isolation and emperically measure the velocity of a team that is doing the work. There are many benefits of doing this. They are separate numbers that come from separate factors!
One major benefit of estimating stories is using the "poker game". The poker game is where the team and customers get together and discuss the stories. Each story is discussed and then each person at the meeting raises a card that shows how many story points they feel should be assigned to the story. The first vote usually shows a wide variation of points. We then discuss the estimates (usually the high & low voting people talk first). This is very beneficial because the unknowns and assumptions are revealed. People take very different views of a feature and this leads to wide variations of expectancies when the feature is estimated. All of this comes out in the discussion of the story being estimated and some of the points make it in as "conditions of satisfaction" for the story.
This process is repeated until the room is pretty close on what the points should be and then we move on.
To estimate an entire release (4 months) of stories took a dozen people an entire day (we had to go offsite so we wouldn't be interrupted). We also have "lookahead" planning sessions where the entire team gets together about once a month to refine the stories (disaggregate larger stories into smaller ones) and estimate those stories.
The end benefit is that teams get a consistent story burndown velocity that allows them to see how well they are tracking their release goals (measured once every 2-week sprint). This is the velocity of real feature development that is far more valuable than estimated hours.
Subscribe to:
Posts (Atom)