Edoardo Schepis

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]