As a user, I want to search the Internet so that I can find information. The document discusses splitting large user stories into smaller ones based on data boundaries, operational boundaries, orthogonal features, and performance constraints. It also discusses estimating user stories in story points and defining a definition of done.

3. Ogni riferimento a fatti realmente accaduti e/o a persone realmente
esistenti è da ritenersi puramente casuale.
Any resemblance to actual persons is purely coincidental

7. As a user I want to search the Internet so
that I find the information I need

8. • Software Engineer
• Scrum Master in Funambol
– 6 teams
– 30 engineers
schepis@funambol.com • 2,5 years = 50 iterations  3000 user stories
• Links:
– http://www.funambol.com
– http://www.edschepis.net
– http://pragmaticagile.wordpress.com
edschepis

9. • Introduction to User Stories
– Epic/Theme/User Story/Task
– INVEST
– Estimation
– DONE!
• Gugol User Stories
• Critics
• Conclusions

11. • In general or for your particular product/service/company,
what would you rather have your customers talk about?
– A. “Their is awesome”
– B. “Their is awesome”
– C. “Their is awesome”
– D. “
”
• First-person language... reverse engineer
• It's not about the tools we build, it's what our tools let them do
• better is... better
Thanks to Kathy Sierra - Talk at Business of Software 2009 [http://www.blip.tv/file/3346148]

12. • What's that? Kent Beck coined the term
user stories in Extreme
• 3C Programming Explained 1 st
Edition, 1999
– Card
– Conversation
– Confirmation
• Limitations
– It's not just “As a ... I want to... so that...”
– Without acceptance tests are open to interpretation
– They require close customer contact throughout the project which in some
cases may be difficult or may be unnecessary overhead
– Can have difficulty scaling to large projects
– Conversation starters... fail to serve as a form of reliable documentation of
the system

13. • User stories provide a small-scale and easy-to-use presentation of
information
– generally formulated in the everyday language of the user
– contain little detail, thus remaining open to interpretation
– should help the reader understand what it is the software should accomplish
–
• Use cases in contrast describe a process and its steps in detail, and
may be worded in terms of a formal model.
– is intended to provide sufficient detail for it to be understood on its own
– a generalized description of a set of interactions between the system and
one or more actors, where an actor is either a user or another system
–

14. • Theme
– a top-level objective that may span projects and products
– a collection (group) of user stories
• Epic
– a large user story: break up epic to several user stories
• User Story
• Task

15. • Independent
– User Stories should be as independent as possible.
• Negotiable
– User Stories are not a contract.
• Valuable
– User Stories should be valuable to the user.
• Estimable
– User Stories need to be possible to estimate.
• Small
– User Stories should be small. Not too small. But not too big.
• Testable
– User Stories need to be worded in a way that is testable

16. • Who (As a...)
– User
– Roles
– Systems?!?
• What (I want to...)
– Action
• Why (so that...)
– Needs

19. • Search engine follow links on the web to request pages that
are either not yet indexed or have been updated since they were
last indexed
• These pages are crawled and are added to the search engine .
Searching a slightly outdated index of content which roughly
represents the content of the web
•
– Accept the user query, checking to match any advanced syntax and checking
to see if the query is misspelled
– Check to see if the query is relevant to other vertical search databases (such
as news search or product search) and place relevant links to a few items
from that type of search query near the regular search results.
– Gather a list of relevant pages for the organic search results. These results
are ranked based on page content, usage data, and link citation data.

20. As a user I want to search the Internet so
that I find the information I need

21. • Why splitting is essential?
– a user story should be split when it is too large to fit within a single iteration
– split a large user story if a more accurate estimate is necessary
• How to split?
– Data Boundaries (the information, the results)
• along the boundaries of the data supported by the story
– Operational Boundaries (search)
• separate CRUD operations
– Orthogonal Features (security, logging)
• creating two versions of the story: one with and one without support
– Performance Constraints (find quickly, millions of users)
• separating the functional and nonfunctional aspects into separate stories
– Mixed Priorities (error paths)
• the priorities of the smaller stories are different.
• Don’t split a large story into tasks
• Watch out the User Stories split f re n z y (“details are not needed now”)

22. As a user I want to search the Internet so
that I find the information I need

23. As a user I want to search the Internet so
that I find the information I need

24. As a user I want to search the Internet so
that I find the information I need

25. As a user I want to search the Internet so
that I find the information I need

26. As a user I want to search the Internet so
that I find the information I need

27. • Data boundaries: search contents, input and results
• Operational Boundaries: searching... “I'm Feeling Lucky”
• Performances and scalability
• Mixed Priorities:
– Ranking
– Advanced Search
– Web Services
– Localized searches

28. • Web Search
– Simple input
– “I'm Feeling Lucky”
– No Ranking
– IP-local searches
– Subset of results
• Data boundaries:
– News Search
– Image Search
– Code Search Advertising
– Maps Search
– ...
• Advanced Search
• Web Services
• Support millions of users

31. • Story Points are units of size used in estimating software
requirements as an alternative to units of time
• Measurement of complexity vs. man-day
• Advantages:
– cheaper to arrive at
– collaborative estimation - it's not just developers who can or do estimate, it is
a product team including analyst, tester and developers
– the estimates of size are more transparent and universally agreed upon
• Planning Poker and other techniques
• Fibonacci sequence

32. • DoD is a checklist of valuable activities required to produce software
– a simple list of activities (writing code, coding comments, unit testing,
integration testing, release notes, design documents, etc.) that add
verifiable/demonstrable value to the product
• DoD is the primary reporting mechanism for team members
– “This feature is done.”
• DoD is equivalent to “potentially shippable”
• DoD is not static

33. 1 2 8 13
2
2
?

35. • Web Search
– Simple input
– “I'm Feeling Lucky”
– No Ranking
– IP-local searches
– Subset of results
• Data boundaries:
– News Search
– Image Search
– Code Search Advertising
– Maps Search
– ...
• Advanced Search
• Web Services
• Support millions of users

36. • Scaling:
more than 4 billion of pages and 10Kb/page = tens of terabytes
– Performances
– Hardware requirements
– Handling Failures
– PageRank and Shards
• Documenting Gugol with a list of “As a user..”?
• Prototypes and Spikes

37. • http://www.mountaingoatsoftware.com
• http://en.wikipedia.org/wiki/History_of_Google
• http://xprogramming.com
• http://www.searchenginehistory.com/
• http://headrush.typepad.com/
• http://pragmaticagile.wordpress.com

39. Focus on what user does, not what you do
Don't build a better [x], build a better [user of x]
Thanks to Kathy Sierra - Talk at Business of Software 2009 [http://www.blip.tv/file/3346148]