The Ultimate Agile Planning Handbook

If you like this presentation – show it...

Slide 0

Slide 1

Traditional vs. Agile Planning is done incrementally. 2 Traditional planning is done prior to investing time and resources in the project.

Slide 2

Traditional planning In traditional planning, significant time and effort are placed into upfront planning and so plan divergence is discouraged. 3 Agile planning Instead of making “big up front plans” agile teams use the time to respond to customer feedback. They recognize that the true value emerges as customers begin to consume the incremental components they receive.

Slide 3

4 Traditional Teams Traditionally run projects are planned by an “expert.” One person is assessing and then producing a plan to deliver the end project. Agile Teams Agile planning is done with the entire team. It promotes the tenet that the people doing the work should be the ones producing the plans as they have the best knowledge about how the work will get done.

Slide 4

Timeboxing in Agile “Timeboxing refers to the act of putting strict time boundaries around an action or activity.”   5 When we timebox an event the result is a natural tendency to focus on the most important “stuff” first. It also guards against “feature creep” -adding features without a scrutinizing relevance or need. FIGURE - ON AN AGILE PROJECT EVERYTHING IS GIVEN A TIME CONSTRAINT

Slide 5

Iterations/Scrums Agile teams break projects down into smaller timeboxed durations- iterations/scrums. An iteration length is fixed, meaning it will end regardless of whether all assigned work is completed. 6 At the beginning of an iteration, a team works with the customer to select an appropriate amount of requirements. After that the team breaks-down those requirements into tasks and at the end of the iteration makes a release. FIGURE - PROJECTS ARE COMPRISED OF FIXED DURATION ITERATIONS.

Slide 6

Backlog - Priority and Size 7 For agile planning to work, the backlog must be prioritized and sized (estimated). A prioritized backlog is simply a list of work that needs to get done that is ordered by priority- the most important work is done first. A sized backlog is another way of saying that the item should have an estimate. FIGURE - PRIORITIZED BACKLOG

Slide 7

8 Backlog - Uncertainty and Maturity Sometimes, when commencing the building of the software, not all requirements are ready so we should also consider the uncertainty and maturity levels of our tasks. FIGURE - ITEMS WITH LOW MATURITY OR LOW CERTAINTY ARE NOT GOOD CANDIDATES FOR ITERATION ASSIGNMENT – TEAM SHOULD SPEND MORE TIME MATURING OR VALIDATING THE REQUIREMENT BEFORE DEVELOPMENT BEGINS

Slide 8

9 Iteration Velocity and Capacity Understanding how much work the team can deliver in one iteration (capacity) is a good estimate of how long (velocity) the project will take. Planning an iteration is very much like using a bucket (iteration) to scoop water out of a pool (backlog). FIGURE - CAPACITY

Slide 9

10 Decomposition into Tasks The backlog is comprised of requirements (user stories - value required by the customers). Those requirements are assigned to the current or the next iteration filling it to capacity and are then decomposed into smaller tasks.   Agile teams much rather have team members assign work to themselves instead of having a project manager assign work to them. FIGURE - ITERATION PLANNING ASSIGNS ITEMS FROM THE PRODUCT BACKLOG TO THE ITERATION BACKLOG AND DECOMPOSES INTO TASKS

Slide 10

11   Release Planning Many (traditional) organizations release a version of their software after a long period of time. Agile companies use a continual release process where features are rolled out to customers as soon as they are complete. The Agile teams begin each release with release planning, and ends each release with a production software release. FIGURE - RELEASES HAVE A SIMILAR STRUCTURE TO AN ITERATION

Slide 11

12 Common Agile Planning Challenges Handling incomplete work at the end of an iteration Handling bugs Handling uncertainty with spikes No time for agile meetings

Slide 12

13 1. Handling incomplete work at the end of an iteration   There are only a few things that teams can do to manage unfinished work: move the work forward into the next iteration (if the task is close to finish) or move it back to the main backlog (if the task was not even started). FIGURE - WORK NOT COMPLETED IN AN ITERATION CAN EITHER MOVE TO THE BACKLOG OR TO FUTURE ITERATIONS.

Slide 13

14 2. Handling Bugs Having bugs is inevitable and must be addressed by all Agile teams. Perhaps the most common way to handle bugs on a project is to allocate a particular amount of capacity in the iteration toward fixing bugs. FIGURE - AGILE TEAMS ALLOCATE A % OF THE CAPACITY OF AN ITERATION FOR BUGS

Slide 14

15 3. Handling uncertainty with spikes Every project will contain a degree of uncertainty. Uncertainty is usually resolved with experimentation and further research. Agile teams dedicate a timeboxed amount of time to addressing uncertainty (spikes). FIGURE - SPIKES ARE SCHEDULED INTO AN ITERATION TO INCREASE CERTAINTY ABOUT TECHNOLOGY OR REQUIREMENTS.

Slide 15

16 4. No time for agile meetings The following four meetings are critical to this process and should never be skipped because they are a critical best practice in Agile planning: Daily standup (Daily Scrum) Iteration planning (Sprint planning) Iteration review (Sprint review) Iteration retrospective (Sprint retrospective) FIGURE - MINIMUM MEETINGS FOR A HEALTHY AGILE TEAM

Slide 16

17 Conclusion There are different valid approaches to development, but the Agile approach has legions of fans around the world. It’s an efficient method to organize complex work into executable chunks while empowering all stakeholders to participate in the process.

Slide 17

18 http://www.telerik.com/agile-project-management-tools/whitepapers/agile-planning-handbook.aspx This presentation was based on the e-book:

Slide 18

19 TeamPulse is an all-in-one agile project management software that helps you manage requirements & bugs, plan releases and track progress while keeping your team constantly connected. Want to put this theory into practice? For more information: http://www.telerik.com/teampulse/ E-mail: TeamPulse@telerik.com  Phone: +1?888?365?2779