6. Process Overview Daily Standup Customer + Dev Team Story Workshop, Conversations, etc Customer Team I-Meet Customer + Dev Team Prioritize stories, estimate velocity R-Meet Customer + Dev Team Prioritize stories, estimate
7. A User Story 3 parts Planning placeholder & reminder Notes from conversations Tests Not system’s point of view
8. User Story – Planning Placeholder & Reminder Taskboard & Release/Sprint Planning (VersionOne*) Card Walls & Release/Sprint Planning (Mingle*) *Mingle is a trademark of Thoughtworks *VersionOne is a trademark of VersionOne
9. Notes from conversations E.g. Customer Service can search for orders so that they can quickly access the customer’s order when customer calls in to make changes to the delivery address Notes : Zie says always show customer name, order reference number, order date.
10. Tests Conveys to developers additional information Developers get an idea if they are done Treat as specification
14. Writing User Stories - Form and function The role, goal and motivation. <role’s> wants to do <goal> because <motivation> Example : As an account holder, I want to transfer funds between two of my accounts so that I can maximize the performance of my savings and avoid any fees associated with overdrafts and minimum balance rules.
15. Writing User Stories - INVEST E.g. of non-independent story : Customer can pay for basket items using iPay88 payment gateway Customer can pay for basket items using WorldPay payment gateway Possible Solutions: Combine both If combining both is too large – split out the base work: Customer can pay with one type of payment gateway Customer can pay with two additional types of payment gateway
16. Writing User Stories – INVEST Too much detail such that the extra details is associated to extra precision – always negotiable Valuable to Users User easily understands : Test with Credit Card, Debit Card and Cheque User cannot understand : Test that Payment table contains the authorization id for credit card Acceptable to indicate non-functional requirements like : This feature is expected to be used by 200 users concurrently and at any one time 200 payment records can be shown quickly, may be in 2s.
22. Writing User Stories - Responsibilities Customer Team : Responsible for writing stories, keeping in mind INVEST Developer : Help customer write stories which lack details, do not assume and always have conversation but have it at the point when supporting information is available
23. Writing User Stories - Trawling for Requirements User stories workshop, interviews ( open ended and context free questions ) , observation & questionnaire Role Modeling, Personas , Extreme characters
24. Writing User Stories - Trawling for Requirements Higher Fidelity Prototype Low Fidelity Prototype Returns/Exchange Status Delivery Input Return Details Refund Details (Based on Payment)
25. Story Smell Catalogues Stories are too small Interdependent Stories Goldplating Too many details Including user interface details too soon Thinking too far ahead Splitting too many stories Customer has trouble prioritizing Customer won’t write and prioritize stories
26. Questions What does INVEST stands for? Who constitute the Customer team? What are the tools available for trawling for requirements?
28. Managing - Planning Too many variables, too far ahead and replanning with better information not planned for 75% of all US IT projects are considered to be failures by those responsible for initiating them. Half of the projects exceeded budget by 200% 31% of projects were cancelled outright 53% of the all projects was so worrying that they were challenged.
29. Managing – Planning.Estimating Establish definition of story points Velocity = (Story Points Completed)/Sprint Previous velocity can be used to estimate Tools : Estimating : Tasks, Triangulating with Card Wall, Planning Poker
32. Managing – Planning.Release Two areas Features/Stories Prioritization : MoSCow Time Iteration Length Time to complete - Product Roadmap Move from story points to expected duration Product will be ready for release in approximately 5-7 iteration
33. Managing – Planning.Sprint Discuss a stories For each stories disaggregate into tasks Small enough to be accurate Developer accepts responsibility for each task Individually ensures estimate What! No task for upfront design?
35. Managing - Rules of the Game No changes to during a sprint Customer stay involves all the time
36. User Stories Not IEEE 830 Use cases – sized to deliver business value, “level of detail” Why Emphasize of quick chat Comprehensible by everyone Right size for planning Works for iterative development Defer details to a right point in time Support opportunistic design Encourages participatory design Build up tacit knowledge Stories may not be good ISO 9001 companies – Will have an issue with tear up stories
37. Team Practices Start off with simple design, but expect changes Refactoring ( and consequently test ) is important Test Automation is crucial Architecture, UML, use cases and agile software development Middle out
38. Questions What are the tools used in estimation? What is done in Release Planning? What are the tools used in Release Planning? Completion vs Number of Stories Points – which is preferred? Name the Team Practices. How do you deal with unplanned tasks?
44. Reference User Stories Applied for Agile Software Development – Mike Cohn – Addison Wesley http://www.thoughtworks.com/what-we-say/presentations/AgileMadeUsBetter.pdf Behavior Driven Development - Scott Belware - http://www.code-magazine.com/articleprint.aspx?quickid=0805061&printmode=true
Hinweis der Redaktion
Human’s capability to design without feedback is poor. Typically large upfront requirements and design will typically changeKey is to find that right balance – finding that balance differ from person to personIdea is start coding at the right time, so requirements can be
Customer team : Product Management, user ( if possible actual user ), testerCustomer PrioritiesDesirability from a broad base usersDesirability of the feature to a small number of important usersCohesiveness Developer PrioritiesTechnical riskCohesivenessStandupMeeting – think about a maximum of 3 things the team like to know about your work
Epic – very large stories with a large value for estimatesUser stories emphasize verbal rather than written communicationComprehensible by both you and the developersRight size for planningUser stories defer details until you have the best understanding about what you really need-> Stories can contain stories, just describe a large story and rip it up later splitting it to multiple stories
How much details is enough? The notes on the card is not important, it’s just to be a reminder, if you can remember don’t put it in.There are details that developers already think they know, it’s important that developer don’t assume – have the conversation and jot things down, don’t get too much detail, start coding first and get the feedback
Who:Customer teamWhen : During conversations between customer + developer and want to capture explicit detailsDedicated effort at the start of an iterationAfter programming of the storyWhat :-What else do the programmers need to know about this story-What am I assuming aout how this story will be implemented-What are the circumstances when this story may behave differently-What can go wrong during this storyFunctional in nature but possible to include ui flow, usability testing, performance testing, stress testingHow Needs to be automated – see fitnesseTesting for bugs not coverageAdd a test for each bug
Stories may not be independent initially, if
Issues, since there will be multiple gateway, the developer spend an upfront design and development for the base components and then provide the specific implementation and testing for each of the gateway
Epics fall into two types : Compound-split but retain cohesivenessComplex – pull research away from functionalityEg. complex algorithm, complex business process
Needs to be testable
Tools : Role ModelingCustomer Team
Constantly adjust plan to reflect the knowledge we gain from each iteration
Can be the 3 hours of solid work half dayCan be the ideal 8 hour work day, etc.Can be the 3 hours of solid work half day of two developers
Not every developer are the same – different backgroundsEstimating as a team levels outEveryone tries to complete as a team – prefers completing stories over starting new ones, Organization Development
Time Select iteration length Time to completePrioritizationBroadbase usersImportant usersCohesivenessCustomer Team Prioritizes with the help of the team
Personally I think upfront design is essential to be efficient, finding out the right balance is important – it should be allocated and the amount of time spend should be short – the longer the more complicated
