Kent Beck
2004-11-15 18:29:11 UTC
Plan using units of customer-visible functionality. "Handle five times
the traffic with the same response time." "Provide a two-click way for
users to dial frequently used numbers." As soon as a story is written,
try to estimate the development effort necessary to implement it.
Software development has been steered wrong by the word "requirement",
defined in the dictionary as "something mandatory or obligatory." The
word carries a connotation of absolutism and permanence, inhibitors to
embracing change. And the word "requirement" is just plain wrong. Out of
1,000 pages of "requirements", if you deploy a system with the right 20%
or 10% or even 5%, you will likely realize all of the business benefit
envisioned for the whole system. So what are the other 80%? Not
"requirements"; they weren't really mandatory or obligatory.
Early estimation is a key difference between stories and other
requirements practices. Estimation gives the business and technical
perspectives a chance to interact, which creates value early, when an
idea has the most potential. When the team knows the cost of features it
can split, combine, or extend scope based on what it knows about the
features' value.
Figure 6: Sample story card
Give stories short names in addition to a short prose or graphical
description. Write the stories on index cards and put them on a
frequently-passed wall. Figure 6 is a sample card of a story I wish my
scanner program implemented. Every attempt I've seen to computerize
stories has failed to provide a fraction of the value of having real
cards on a real wall. If you need to report progress to other parts of
the organization in a familiar format, translate the cards into that
format periodically.
One feature of XP-style planning is that stories are estimated very
early in their life. This gets everyone thinking about how to get the
greatest return from the smallest investment. If someone asks me whether
I want the Ferrari or the minivan, I choose the Ferrari. It will
inevitably be more fun. However, as soon as someone says, "Do you want
the Ferrari for $150,000 or the minivan for $25,000?" I can begin to
make an informed decision. Adding new constraints like "I need to haul
five children" or "It has to go 150 miles per hour" clear the picture
further. There are cases where either decision makes sense. You can't
make a good decision based on image alone. To choose a car wisely you
need to know your constraints, both cost and intended use. All other
things being equal, appeal comes into play.
------------------------ Yahoo! Groups Sponsor --------------------~-->
Make a clean sweep of pop-up ads. Yahoo! Companion Toolbar.
Now with Pop-Up Blocker. Get it for free!
http://us.click.yahoo.com/L5YrjA/eSIIAA/yQLSAA/nhFolB/TM
--------------------------------------------------------------------~->
the traffic with the same response time." "Provide a two-click way for
users to dial frequently used numbers." As soon as a story is written,
try to estimate the development effort necessary to implement it.
Software development has been steered wrong by the word "requirement",
defined in the dictionary as "something mandatory or obligatory." The
word carries a connotation of absolutism and permanence, inhibitors to
embracing change. And the word "requirement" is just plain wrong. Out of
1,000 pages of "requirements", if you deploy a system with the right 20%
or 10% or even 5%, you will likely realize all of the business benefit
envisioned for the whole system. So what are the other 80%? Not
"requirements"; they weren't really mandatory or obligatory.
Early estimation is a key difference between stories and other
requirements practices. Estimation gives the business and technical
perspectives a chance to interact, which creates value early, when an
idea has the most potential. When the team knows the cost of features it
can split, combine, or extend scope based on what it knows about the
features' value.
Figure 6: Sample story card
Give stories short names in addition to a short prose or graphical
description. Write the stories on index cards and put them on a
frequently-passed wall. Figure 6 is a sample card of a story I wish my
scanner program implemented. Every attempt I've seen to computerize
stories has failed to provide a fraction of the value of having real
cards on a real wall. If you need to report progress to other parts of
the organization in a familiar format, translate the cards into that
format periodically.
One feature of XP-style planning is that stories are estimated very
early in their life. This gets everyone thinking about how to get the
greatest return from the smallest investment. If someone asks me whether
I want the Ferrari or the minivan, I choose the Ferrari. It will
inevitably be more fun. However, as soon as someone says, "Do you want
the Ferrari for $150,000 or the minivan for $25,000?" I can begin to
make an informed decision. Adding new constraints like "I need to haul
five children" or "It has to go 150 miles per hour" clear the picture
further. There are cases where either decision makes sense. You can't
make a good decision based on image alone. To choose a car wisely you
need to know your constraints, both cost and intended use. All other
things being equal, appeal comes into play.
------------------------ Yahoo! Groups Sponsor --------------------~-->
Make a clean sweep of pop-up ads. Yahoo! Companion Toolbar.
Now with Pop-Up Blocker. Get it for free!
http://us.click.yahoo.com/L5YrjA/eSIIAA/yQLSAA/nhFolB/TM
--------------------------------------------------------------------~->