Alla ricerca della User Story perdutaFirenze, 6 Maggio 2010

Edoardo SchepisScrum Master

Funambol

... ovvero come creare “un” motore di ricerca attraverso l'uso delle User Stories

Ogni riferimento a fatti realmente accaduti e/o a persone realmente esistenti è da ritenersi puramente casuale.

Any resemblance to actual persons is purely coincidental

E' il 1996...

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

Me

• Software Engineer • Scrum Master in Funambol

– 6 teams– 30 engineers

• 2,5 years = 50 iterations 3 000 user stories

• Links:– http://www.funambol.com– http://www.edschepis.net– http://pragmaticagile.wordpress.com

edschepis

schepis@funambol.com

Agenda

• Introduction to User Stories– Epic/Theme/User Story/Task– INVEST– Estimation– DONE!

• Gugol User Stories• Critics• Conclusions

Quiz

• In general or for your particular product/service/company, what would you rather have your customers talk about?– A. “Their product is awesome”– B. “Their service is awesome”– C. “Their company is awesome”– D. “I am awesome”

Thanks to Kathy Sierra - Talk at Business of Software 2009 [http://www.blip.tv/file/3346148]

• First-person language... reverse engineer• It's not about the tools we build, it's what our tools let them do• Being better is... better

User Story

• What's that?• 3 C

– 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

Kent Beck coined the term user stories in Extreme

Programming Explained 1 st

Edition, 1999

User Stories vs. Use Cases

• 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– User stories are about needs

• 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– Use cases are about the behavior you’ll build into the software to

meet those needs

Epic, Theme, Story, Task

• 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

INVEST in User Stories

• 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

Define User Story

• Who (As a...)– User– Roles– Systems?!?

• What (I want to...)– Action

• Why (so that...)– Needs

Defining Gugol Search Engine

• Search engine spiders 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 index. Searching a slightly outdated index of content which roughly represents the content of the web

• Search interface and relevancy software– 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.

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

Slice the feature• 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 r enzy (“details are not needed now”)

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

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

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

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

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

Gugol User Stories

• 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

Gugol User Stories• Web Search

– Simple input– “I'm Feeling Lucky”– No Ranking– IP-local searches– Subset of results

• Data boundaries:– News Search– Image Search– Code Search– Maps Search– ...

• Advanced Search• Web Services• Support millions of users

Advertising

Estimation

Let's Try!

For example...

Estimation and Story Points

• Story Points are units of relative 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

Definition of Done

• 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

For example...1 2 8

2

13

2 ?

Gugol estimates (collaborative)

Let's try!

Gugol User Stories• Web Search

– Simple input– “I'm Feeling Lucky”– No Ranking– IP-local searches– Subset of results

• Data boundaries:– News Search– Image Search– Code Search– Maps Search– ...

• Advanced Search• Web Services• Support millions of users

Advertising

… and now?

• 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

References

• 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

Q&A

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]

Alla ricerca della User Story perdutaFirenze, 6 Maggio 2010

Edoardo SchepisScrum Master

Funambol