Development Processes Agile Adaptive Planning. Stefan Sobek

Transcription

1 Development Processes Agile Adaptive Planning Stefan Sobek

2 Agile Planning Process Adaptive Planning In agile projects frequently issues and changes will be discovered. Go into these projects with expectations to adapt the plan. Agile vs. Non-Agile Planning Trial and demonstration uncover the true requirements, which then Agile Planning differs require replanning Agile planning is less of an up-front effort, and is instead done throughout the project Midcourse adjustments are the norm

3 Agile Planning Process Value Based Analysis Work item 1 Work item EUR Business Benefit Work item EUR Business Benefit 5000 EUR Business Benefit 4000 EUR Cost to build Work item EUR Business Benefit 1000 EUR Cost to build Understanddeliveryandbuildingcosts whenanalysingwhichwork item has the highest business value

4 Timeboxing Agile planning and development are based on the concept of timeboxing Time Scope defined by plan fixed Cost Cost variable defined by use Scope Time Agile timeboxes can be from minutes to weeks, e.g. Daily stand-up meetings are timeboxed to 15 minutes Retrospectives are often timeboxed to 2 hours Iterations and sprints are typically timeboxed to one to four weeks Timeboxes allow agile teams to adjust scope to achieve the highest-priority, best-quality product within a fixed cost and timeframe

5 Timeboxing Iteration Timebox Has a fixed capacity The team loads the work items (user stories) into the timebox in order of priority If the box is full, the lower priority items have to wait The team decides, when the box is full of user stories (how much the can achieve in the timebox)

6 Sizing, Estimating and Planning Size How big is it? Estimate How quickly can we get through it? Plan When can we do it?

7 Decomposing Requirements Work that cannot be accurately sized, estimated and planned à need to be decompose or break down 3 examples to structure requirements: Epic Epic Feature User Story User Story User Story Feature Feature Epic Epic Task 1 Task 2 User Story User Story User Story Task 1 Task 2 User Story User Story User Story Task 1 Task 2 There is no right way to structure a requirements hierarchy Some teams add epics, which are large user stories that span over more iterations. Some addepics above orbelow features Or epic might be used in place of feature.

8 User Stories User stories are small chunks of business functionalilty within a feature Involve roughly 1 to 3 days of work (4 to 40 hours roughly) Agile teams break down work into User Stories Will be put on the prioritized product backlog

9 User Stories Focus Business Value Purpose User point of view User stories are short, simple description of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system. As a <type of user>, I want <some goal> so that <some reason>. Should contain acceptance criteria à when is the user story done When done it should have created a usable feature. There is no right template, but they are often written in the format given above

10 Characteristics of Effective User Stories User Stories should follow the INVEST acronym Independent We want to be able to develop in any sequence. Negotiable Avoid too much detail; keep them flexible so the team can adjust how much of the story to implement. Valuable Users or customers get some value from the story. Business Value for the customer is the key. Estimatable The team must be able to use them for planning. Small Large stories are harder to estimate and plan. By the time of iteration planning, the story should be able to be designed, coded, and tested within the iteration. Testable Document acceptance criteria, or the definition of done for the story, which lead to test cases.

11 Relative Sizing and Story Points Estimation typically based on the Fibonacci Sequence Size of a User Story can be 1,2,3,5,8... nothing in between The team shold own the definitions of their story points E.g. one point is developing a simple screen Story point estimates should be all-inclusive No extra effort for testing, refactoring... All-in!!! When disaggregating estimates, the totals don t need to match Sum of smaller units (e.g. tasks) doesn t need to sum up to the effort of the bigger item Complexity, work effort, and risk should be included in estimates Total time required must be in the estimate.

12 T-Shirt sizing Estimate by T-Shirt sizes (e.g. XS, S, M, L, XL, XXL) E.g. Online movie services has the following features: Rate movies Browse movies Sell movies Review movies Sort movies by year XS S M L XL XXL Sort movies by year Rate movies Browse movies Review movies Rent movies Sell movies

13 Planning Poker Collaborative game for estimation Cards represents Story Points Process: Example Story: As a customer I want to be able to change my adress When everybody is ready, facilitator count to three and everybody shows a card Estimates are 3,5,3 and 13 So you ask the person with 13 why, to find out if the others may missed some effort or added effort on top. à Leads to discussion and understanding of the User Story

14 Daily stand-ups (daily scrum) Short and focused team meeting Everybody stands 15-Minute timebox (meeting is over after 15 minutes!!!) Answer 3 questions: What did I worked on since last meeting? What am I planning to finish today? Any problems or impediments? After the meeting some members can discuss topics or problems Everybody knows the status