7. Simple, clear, short description of customer valued functionality. 3 C’s: Card, Conversation, Confirmation. Represents customer requirements.
8. Priority: Title: As a [type of user], I can [goal] so that [value] Notes: Assumptions: Constraints: Estimate:
9. Checkout Using Credit Card 25 As a book shopper, I can checkout using my credit card so that I can purchase a selected book. Notes: Support mc, visa, amex Constraint: Must use Chase payment service 13 pts
11. Checkout Using Credit Card Test with valid mc, visa, amex passes Test with valid other cards fails Test with expired card fails Test with invalid cvv fails Test with invalid zip fails
12. Priority: Title: As a [type of user], I can [goal] so that [reason] Notes: Assumptions: Constraints: Estimate:
13. Title: Priority: As a [type of user], I can [goal] so that [reason] Notes: Assumptions: Estimate: Constraints: “Get smaller cards”
14. How do I describe what I want? How do I schedule this work and track its progress? How do I validate that this work is done? What are the details of what I need to code?
Acknowledgments:Mike Cohn’s User stories applied and Agile Estimation and Planning. Jeff Patton’s work on User Role Modeling.
Mike Cohn:simple, clear, short description of customer valued functionality 3 parts: written description used for planning, conversation to flesh out details, tests to determine completeness.Ron Jefferies: 3Cs - Card, conversation, confirmation.Rachel Davies: user story represents customer requirements rather than documents them.
Template: As a type of user, I can achieve some goal so that I can gain some value.Add a title, some notes, assumptions, constraints, priority, estimate.
Examples
On the back, we add acceptance criteria.Use this template for acceptance tests: Given [context] And [some context] When [event] Then [outcome] And [another outcome].Or simpler version of verify or test.
Examples
Too much info. Running out of room?
Tom Poppendieck advises us to use smaller card.User story covers the who, what and why? It does not cover how? That is where the conversation comes in.
The main purpose of a story is to act as a reminder and encourage conversation to flush out details the closer we are to implementing a story.Business, PM, Developer, TesterPicture :http://www.flickr.com/photos/improveit/1470706210/in/photostream
IEEE 830: The system shall…1000 requirements in Excel, become 30 functional specs, each about 50 pages.Hand it over to the developers and testers (1500 pages).Process is tedious, error prone, time consuming, boring, hard to see the big picture, hard to prioritize, not goal focused (task oriented). Use cases do a better job at putting things in context, but are still too detailed to adapt to changing customer need.They are bigger, larger in scope, there is the main scenario and then the extensions, pre/post conditions. They act more as an agreement between customer and developer rather than a forum for conversation.
User stories directly support the Agile manifesto:User stories support focusing on working software over comprehensive documentation.Conversation supports individuals and interactions and customer collaboration.Brevity and high level of user story supports responding to change.
Emphasize verbal rather than written communication.Encourage conversation, face to face discussions as opposed to document handoffs.
Encourage deferring details until you have better understanding about what you really need.Avoids unnecessary detailed planning which might change by the time we reach development time.
Provide right size for planning.High level, focus on value and can be prioritized.
Comprehensible by customers and developers.Picture: http://www.flickr.com/photos/90001203@N00/172506278/
Works for iterative development.Start at high leveland flush out details with each iteration and repeat.
Use human user. Write story from user’s perspective and understand his goal and value for the story.Avoid using generic as a user or as a customer. Think of role as group of users that share common characteristics and based on those characteristics their interactions with system will be different. Think penny pinching college student, busy corporate lawyer, or juggling mother of 3. Try to profile roles and figure out how often will they use the system, how much domain knowledge do they have, are they technically savvy, what is their goal? Pain points?Use extreme users. Extreme users are not really target audience, but simply bringing them up can produce different context and lead to interesting discussion. For example, think of the Pope. Or think of a hacker.As a hacker, I can access customer’s payment information to pay for my vacation.Picture: http://www.flickr.com/photos/12426416@N00/163959411
More examples
More examples
Bill Wake - Invest acronym: Independent, negotiable, valuable, estimatable, small, and testable. Picture: http://www.flickr.com/photos/42179515@N06/3937449949
Independent: try to make sure that stories are not interdependent as this might lead to prioritization and planning problems.Independent is different from logical order of developing things. By independent, we mean story features. For example, in earlier credit card example, we wanted to support amex, mc and visa. If there are 2 stories, one for mc and another for visa, then estimates will depend on which one gets done 1st because implementing the 2nd will be relatively straight forward.Options are to combine the stories, or split in a different way (discussed later).If for some reason dependency cannot be removed, then provide 2 estimates on each story, one for each order combination.
Negotiable: Brief and not a detailed contract.Encourage conversation and negotiation between customer and developers.Picture: http://www.flickr.com/photos/23065375@N05/2235525962
Valuable: Provide value to the customer or the user.Start with goal stories and break it out from there.Standish Group: 64% of features are never or rarely used in reality.Ensure value is written. If customer cannot think of value, then they might see work as unnecessary and eliminate it.If value is clearly specified, team might find different ways to achieve same goal with same value but with less effort.Because story is delivering piece of functionality, customer can figure out how much functionality costs and then decide if they still need it.Not all value is monetary, mitigating risk is value.As a [type of user] I want [some functionality] to avoid [some operational risk, process weakness, ...]
Estimatable:Developers need to estimate story.Story needs to be written so developers can understand it and have idea of how to implement it.Reasons we can’t estimate are lack of domain knowledge, lack of technical knowledge, or too big.Picture: http://www.flickr.com/photos/21458229@N00/4553607341
Small: Not too big, not too small, but just right (1 story half the iteration length).Provide focus and short horizon for the team. Its easier to get lost in the details with larger story.Easier to adapt and give flexibility to reconfigure and adapt to changes.Large stories increase risk that team will deliver nothing at end of iteration.Large stories cancreate blockages and bottlenecks. One person who is tied up in large story may also be only person who can complete key piece of another story.Picture: http://www.flickr.com/photos/24257141@N05/4747161154
Testable: Need to verify that story is complete.Make sure there is acceptance criteria.Non-testable stories usually occur with non-functional requirements: Ease of use, fast, bug free.Try to re-write so that some metric can be measured and test can be written (ideally automated). Example: Test that system responds in 1 second or less at least 95% of the time.Picture: http://www.flickr.com/photos/20897132@N00/208837407
DependencyStory dependent on another story makes it hard to give correct estimate.Split so one story handles dependency and other handle specifics.Picture: http://www.flickr.com/photos/15923063@N00/4972049904
Size – Too bigCannot give accurate estimate: Story needs to be more manageable and enable more accurate estimate.Cannot fit into iteration: If for example iteration is 1 week long and story is longer than week then it needs to be split to fit into iteration.Cannot fit into what’s remaining of iteration: Team has already committed to 38 story points and there is still room for 2 point story but remaining stories are 3 story points or more.Picture: http://www.flickr.com/photos/87857621@N00/191311751
Risk:If complex and risky, split to create spike story which is experimental in nature with main goal to gain technical knowledge.Picture: http://www.flickr.com/photos/95457978@N00/495352477
Story contains multiple sub stories that are large enough to stand out on their own.
Combine many small items onto one larger story.Example: Bug reports can be combined into one “Fix Bugs” story.
Slice Vertically: Stories should represent some level of end to end functionality. This reduces overall risk and delivers value to customer.Do simplest thing that could possibly work.Important to not split stories into tasks like design, code front end, code middle tier, code back end.Better to deliver cohesive subset of all layers of feature than delivering all of one layer as standalone.Having entire backend ready without corresponding GUI is not very useful.Having feature that allows user to add entity through GUI and have it persisted is functionality that can be useful and provides some value.
Data Boundaries: Separate local requirements from international requirement.Handling one type of credit card from another.Start with USD then add foreign currency.Picture: http://www.flickr.com/photos/7762644@N04/2533281806
Operational boundaries:CRUD boundaries.Separating into search which returns search result count and then search display which displays actual results.Happy path 1st , exceptions next.Picture: http://www.flickr.com/photos/7729940@N06/3076476665
Cross Cutting Concern: Features that effect multiple aspects of the application like security, logging, error handling can each be separated out of main functionality features.Screen with different menu options based on the login user’s credentials.Security specific feature can be split from main functionality of screen.Picture: http://www.flickr.com/photos/53611153@N00/303892944
Performance constraints:Split functional requirement from non functional requirements.Example: Feature can be enabled without caching and then another story can handle caching specifics.Picture: http://www.flickr.com/photos/32165728@N00/183211819
Priority:Multiple priorities within a story.Login story might have different priorities for authentication than for handling error conditions like locking out user after multiple logins.Necessity: Minimum needed to get working software.Flexibility: What are some alternative ways of doing it, what additional data we want to capture.Safety: Better validation rule to avoid ugly error messages.Comfort, luxury, and performance: More usable, sexier to look at (animation), hot keys.Opening game: Skeleton spans system and contains necessary features2. Mid game: Add capability, flexibility and safety3. End game: Finish with usability, performance, sex appeal and reserve time for unforeseen additions and adaptationsPicture: http://www.flickr.com/photos/15639842@N00/4182148160
![AGENDA ,[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)