Your SlideShare is downloading. ×
0
Agile stories, estimating and planning
Agile stories, estimating and planning
Agile stories, estimating and planning
Agile stories, estimating and planning
Agile stories, estimating and planning
Agile stories, estimating and planning
Agile stories, estimating and planning
Agile stories, estimating and planning
Agile stories, estimating and planning
Agile stories, estimating and planning
Agile stories, estimating and planning
Agile stories, estimating and planning
Agile stories, estimating and planning
Agile stories, estimating and planning
Agile stories, estimating and planning
Agile stories, estimating and planning
Agile stories, estimating and planning
Agile stories, estimating and planning
Agile stories, estimating and planning
Agile stories, estimating and planning
Agile stories, estimating and planning
Agile stories, estimating and planning
Agile stories, estimating and planning
Agile stories, estimating and planning
Agile stories, estimating and planning
Agile stories, estimating and planning
Agile stories, estimating and planning
Agile stories, estimating and planning
Agile stories, estimating and planning
Agile stories, estimating and planning
Agile stories, estimating and planning
Agile stories, estimating and planning
Agile stories, estimating and planning
Agile stories, estimating and planning
Agile stories, estimating and planning
Agile stories, estimating and planning
Agile stories, estimating and planning
Agile stories, estimating and planning
Agile stories, estimating and planning
Agile stories, estimating and planning
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Agile stories, estimating and planning

7,543

Published on

Published in: Technology, Business
0 Comments
16 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
7,543
On Slideshare
0
From Embeds
0
Number of Embeds
6
Actions
Shares
0
Downloads
490
Comments
0
Likes
16
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Agile Stories, Estimating and Planning www.torak.com Vision Roadmap Release Iteration Daily Story
  • 2. About Dimitri Ponomareff Dimitri Ponomareff (www.linkedin.com/in/dimka5) is a Coach. Whether it's a sports team, software products or entire organizations, Dimitri has that ability to relate and energize people. He is consistently recognized as a very passionate and successful change agent, with an overwhelming capacity to motivate and mobilize teams on their path to continuous improvements. He is a master facilitator, as well as a captivating speaker with consistent, positive feedback regarding his ability to engage an audience. www.torak.com As a certified Coach, Project Manager and Facilitator of "The 7 Habits of Highly Effective People", Dimitri brings a full spectrum of knowledge in his delivery of methodologies. Through teaching by example, he is able to build teams of people who understand where to focus their work to generate the most value. He has coached and provided tailor-made services and training for a multitude of organizations. The short list includes, American Express, Charles Schwab, Bank of America, Morgan Stanley, Choice Hotels International, JDA Software, LifeLock, First Solar, Mayo Clinic and Phoenix Children's Hospital. Dimitri enjoys his work, and does everything to ensure he shares his knowledge with others who seek it.
  • 3. Agile background for stories, estimating and planning ●The Agile Manifesto ●Communication ●PDCA - Plan, Do, Check, Act ●Why, What & How www.torak.com
  • 4. The Agile Manifesto We are uncovering better ways of developing software by doing it and helping others do it. Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. Source: www.agilemanifesto.org www.torak.com
  • 5. Project Management is all about communication People who want IT must communicate with people who can build IT. www.torak.com
  • 6. Effective communication Agile Software Development: Communicating, Cooperating Teams By Alistair Cockburn - Aug 10, 2009 www.torak.com
  • 7. PDCA - Plan, Do, Check, Act ACT PLAN DO PDCA Cycle CHECK Continuous Improvements www.torak.com
  • 8. Why, What & How ●WHY are we doing this? Voice of the stakeholder (Stakeholders) ●WHAT needs to be done? Voice of the user (Product Owner, Subject Matter Expert) ●HOW do we build it? Voice of the developer (Scrum Team) www.torak.com
  • 9. Agile Stories ●Work breakdown structure (WBS) ●What is a story? ○Story form ○Cards - Conversation - Confirmation ●Story writing workshops ○Epics and story breakdown ○INVEST guideline ●Stories vs. Use Cases vs. Requirements ●Product Backlog of stories www.torak.com
  • 10. Alternative to Work Breakdown Structure (WBS) Activity Functionality Analysis Design Coding Testing Feature Feature Feature Module Module Module WBS or traditional projects Functionality Activity Story Story Story Story Analysis Design Coding Feature Breakdown Structure Testing Define the project plan in terms of what will be delivered rather than what work steps will be performed. www.torak.com
  • 11. What is a User Story? ● User Stories provide a light-weight approach to managing requirements for a system. ● A short statement of function captured on an index card and/or in a tool. ● The details are figured out in future conversations between the team and the product owner or customers. ● This approach facilitates just in time requirements gathering, analysis and design by the following activities: ○ Slicing user stories down in release planning ○ Tasking user stories out in sprint planning ○ Specifying acceptance test criteria for user stories early in development www.torak.com
  • 12. Story form As a < role > I can < activity > so that < business value > ● Role - represents who is performing the action. It should be a single person, not a department. It may be a system if that is what is initiating the activity. ● Activity – represents the action to be performed by the system. ● Business Value – represents the value to the business. Why is this story important? www.torak.com
  • 13. Acceptance criteria ● like stories it's written in simple language ● define the conditions of success/satisfaction ● provide clear story boundaries ● remove ambiguity by forcing the team to think through how a feature or piece of functionality will work from the user’s perspective ● checklist or template of things to consider for each story ○ list of impacted modules and/or documents ○ specific user tasks, business process or functions ● establish the basis for acceptance testing ○ steps to test the story (given-when-then scenarios) ○ type of testing (manual vs. automated) www.torak.com
  • 14. The 3 C's 1. Card Written on a card 2. Conversation Details captured in conversations 3. Confirmation Acceptance criteria confirm that the story is Done. Source: XP Magazine 8/30/01, Ron Jeffries As a user, I can login and gain access to the intranet, so that I can collaborate with all the organization. What about expired accounts? Can it remember my login? - Expired accounts fail - Remember the login, not the password - After 3 attempts the account is locked out for 24h (SOX compliance) www.torak.com
  • 15. Story writing workshops ●define clear roles: facilitator and story writer (capture) ●include the entire team and anyone who can express the WHAT aligned to the WHY (subject matter experts, users, customers, etc...) ○ all participants must stay away from the HOW ○ promote open discussion and use open ended questions ●consider using story-boarding technique ○ work around themes/features ○ begin with the end in mind ●write as many stories as possible, plan for 2-4 hours ○ no need for prioritization ○ high level acceptance criteria www.torak.com
  • 16. Product, Epics & Stories Story Story Story Story Story Story Story Story Story Story Story Story Story Story Story Story Story Story Product Epics Stories www.torak.com
  • 17. Start with Epics and break down into Stories As a frequent flyer, I want to rebook a room I take often As a frequent flyer, I want to book a room using miles As a frequent flyer, I want to request an upgrade As a frequent flyer, I want to check if my upgrade cleared. As a frequent flyer, I want to book a room. As a frequent flyer, I want to check my account. As a frequent flyer, I want to … Frequent flyer www.torak.com
  • 18. INVEST guideline from Bill Wake I - Independent The user story should be self contained, in a way that there is no inherent dependency on another user story. N - Negotiable User stories, up until they are part of a Sprint, can always be changed and rewritten. V - Valuable A user story must deliver value to the end user. E - Estimable You must always be able to estimate the size of a user story. S - Sized appropriately User stories should not be so big as to become impossible to plan/task/prioritize with a certain level of certainty. T - Testable The user story or its related description must provide the necessary information to make test development possible. www.torak.com
  • 19. Stories vs. Use Cases vs. Requirements Stories Use Cases Requirements Goal generate conversation capture a behavior establish a contract Scope a single activity a process "day in the life" everything Format a single sentence numbered bullets specifications Completeness open for negotiation and refinements locked, changes may impact entire process locked, require scope change and approvals Language simple, comprehensible structured, flows precise, technical www.torak.com
  • 20. Product Backlog of stories ●a list of all desired work on the project “The requirements” ●owned, managed and prioritized by the Product Owner ●items estimated by the team ●re-prioritized at the start of each iteration ●ideally expressed such that each item has value to the users or customers of the product www.torak.com
  • 21. Estimating ●The cone of uncertainty ●What is estimation? ●Estimation tools/techniques ●Story estimation ○Story points ○Task board ○SMART tasks ○Burn-down chart www.torak.com
  • 22. The Cone of Uncertainty www.torak.com
  • 23. What is estimation? ●Estimation calculated approximation of a result which is usable even if input data may be incomplete or uncertain ●Estimate to judge tentatively or approximately the value, worth, or significance of ●Point estimation estimation in which a single value is assigned to a parameter www.torak.com
  • 24. Estimation tools: T-shirts, Points & Hours Cone of Uncertainty 13853210 20 ? Hours XS S XLLM www.torak.com
  • 25. Story Estimation Size DurationCalculation 240 miles 4 hours Speed 60 MPH 180 points 6 sprints Velocity 30 pts/sprint www.torak.com
  • 26. Story Points ●Measure “bigness” ○COMPLEXITY – How difficult it seems? ○EFFORT - How much of it there is? ○RISK - Current knowledge (uncertainty) ●Relative values ○Unit-less (dog points) ○Use analogy – triangulate with other stories ●Estimation values ○0, 1, 2, 3, 5, 8, 13, 20, 40, 100 ○Planning poker www.torak.com
  • 27. An task board www.torak.com
  • 28. SMART Tasks This is the same SMART approach used with setting effective goals but for tasks. S – Specific The task is specific enough that everyone can understand what's involved and prevents overlapping. M – Measurable The team can measure that the task is Done. This requires the team to have a clear definition of Done. A – Achievable The task is achievable by whoever from the team takes on this work. R – Relevant Every task should be relevant by contributing directly to a story and each task can be explained/justified. T – Time-boxed A task should be time-boxed by setting the right expectation for how long it should take to complete the task. www.torak.com
  • 29. Sprint Burn-down www.torak.com
  • 30. A sprint backlog ● Individuals sign up for work of their own choosing - work is never assigned ● Estimated work remaining is updated daily ● Any team member can add, delete or change the sprint backlog ● Work for the sprint emerges ● If work is unclear, define a sprint backlog item with a larger amount of time and break it down later Tasks Mon Tue Wed Thu Fri Code the user interface 8 4 8 0 0 Code the middle tier 16 12 10 4 0 Test the middle tier 8 16 16 11 8 Write the online help 12 Write the foo class 8 8 8 8 8 Add error logging 8 4 0 www.torak.com
  • 31. Planning ●Planing process ●Levels of planning ○Release planning ○Iteration planning ○Daily planning www.torak.com
  • 32. Planning process Product Roadmap R1 R2 R3 Rn Release 1 SP1 Iteration 1 ST1 STnST3ST2 Iteration n ST1 STnST3ST2 Story 1 T1 TnT3T2 Story n T1 TnT3T2 SPnSP3SP2 Release n SP1 SPnSP3SP2 www.torak.com
  • 33. Levels of planning Release Plan (months) Iteration Plan (weeks) Daily Plan (days) Product Backlog Sprint Backlog Stories Tasks ActivitiesActivitiesActivities www.torak.com
  • 34. Release planning ● Overall context and prioritization for a specific period of time ● Product Owner ○ Creates a goal for the release ○ Selects a number of user stories from the product backlog ○ Works with the team to decompose and estimate the user stories ● The outcome of the release planning process is ○ Release Data Sheet ○ Release Backlog ○ Release Burndown Chart www.torak.com
  • 35. Iteration planning ● Team selects stories from the product backlog they can commit to completing ● Sprint backlog is created ○ Tasks are identified and each is estimated in hours ○ Tasks and estimates are done collaboratively ● High-level design is considered As a vacation planner, I can see photos of the hotels, so that ... 8 points Tasks Hours Code the middle tier 8 Code the user interface 4 Write test fixtures 4 Code the foo class 6 Update performance tests 4 www.torak.com
  • 36. Daily planning Parameters ● Daily ● 15-minutes ● Stand-up ● Not for problem solving Three questions for each scrum team member 1. What did you do yesterday? 2. What will you do today? 3. Is anything in your way? These are not status for the Agile Project Manager, they are commitments in front of your peers www.torak.com
  • 37. Agile Coaching, Staffing and Training. Learn more at www.torak.com Learn more at www.AgileTestingFramework.com
  • 38. Thank You www.torak.com
  • 39. Resources and References ● www.scrumalliance.org ● www.mountaingoatsoftware.com/scrum ● www.controlchaos.com ● Agile and Iterative Development: A Manager’s Guide by Craig Larman ● Agile Estimating and Planning by Mike Cohn ● Agile Project Management with Scrum by Ken Schwaber ● Agile Retrospectives by Esther Derby and Diana Larsen ● Agile Software Development Ecosystems by Jim Highsmith ● Agile Software Development with Scrum by Ken Schwaber and Mike Beedle ● Scrum and The Enterprise by Ken Schwaber ● User Stories Applied for Agile Software Development by Mike Cohn www.torak.com
  • 40. This presentation was inspired by the work of many people and we have done our very best to attribute all authors of texts and images, and recognize any copyrights. If you think that anything in this presentation should be changed, added or removed, please contact us. http://creativecommons.org/licenses/by-nc-nd/3.0/ www.torak.com

×