15 Steps to Agile Project Planning Success

Project planning has been around a long time. It started with the building of the Great Pyramid of Giza in about 2580 BC or some 4,600 years ago. To demonstrate that project politics remains little changed since, below is a transcript of one of the conversations between the Pyramid project manager and the principle stakeholder and chief sponsor, Pharaoh. It should sound very familiar:

Pharaoh Khufu: Project Manager Rahotep, a while ago you committed to completing stone course 38 on my Great Pyramid here in Giza before the Moon blazes full 6 times, which, according to my temple astrologers, the 6th time will happen in two Ra days. You’re still one course short, do you want to visit my crocodile farm?
PM Rahotep: My great Pharaoh, according to my well documented papyrus project plan, we will finish the 38th course of stone in two days, nothing to worry about.
Pharaoh Khufu: I, the great Pharaoh Khufu, never worries but you just might start.
Rahotep: Start what?
Pharaoh Khufu: WORRYING! See you in two days and it better be done or else!

Project Manager Rahtep is in big trouble because no matter how great the project plan is, predicting dates 6-months in advance will not be accurate. Pharaoh Khufu doesn’t want to hear about problems or delays, he just knows that the pyramid team ‘promised’ full delivery of the 38th course of stone by a very specific date and heads will literally roll if the date is missed.

Agile Planning

Agile and Scrum attempt to change this kind thinking and replaces long-term planning based on dates with identifying the most valuable or most important work and scheduling it first. If the team can deliver the most important stuff to the customer first, it may not be necessary to all the originally planned work because the customer finds they don’t need it. Agile still does planning so it’s clear when customers and business stakeholders can expect problem solutions but accuracy is lost beyond the 1-2 month time frame. Dates are replaced with release time frames. Here is a guide to estimation accuracy based on my experiences:

  • 1-2 months – 80% accurate
  • 2-4 months – 50% accurate
  • > 4 months – < 50% accurate

This post will look at how to do Agile planning successfully. Agile planning involves everyone at one stage or another; customers, users, testers, developers, product managers, product owners, business managers, BA’s, UXD’s, and other stakeholders. There are several ways the run a planning session but I particularly like Story Mapping by Jeff Patton.

A key outcome of Agile planning will be a common understanding of what needs to be done to solve customer problems and achieve the business goals. Artifacts will include big and small tasks (stories) that will be done to achieve the goals and a general idea in which release these tasks will be completed. Underlining all this will be conversations that fill the gaps the artifacts themselves can not fill. A successful Agile planning session will put testers, developers, product managers, product owners, business managers, BA’s, UXD’s, and other stakeholders all on the same page using the artifacts as a means to remember conversations.

Preparing for the Agile planning session

The planning session will run more smoothly and take less time if you’re prepared. The Scrum Master (or Agile Project Manager), Chief Product Owner, and Product Owner will ensure these tasks are completed before the session:

  1. Define a goal or goals, what everyone will work toward.
  2. Identify the customers, users and key stakeholders. Understand the problems each has.
  3. Conduct customer/user interviews. The best would be a video of a user using the product (see Rocket Surgery Made Easy by Steve Krug: Usability Demo for an excellent example). If a video or audio recording isn’t available, a transcript will work.
  4. Go through each of the customer problems and order these by business value. Businesses could use acquisition, activation, retention, referral, revenue, or other business measures. Any and all are good as long as the measures are applied equally for all problems.
  5. UXD and Product Manager create any necessary wireframes, mockups, or prototypes to use for validating customer problems. Discard those problems that are not valid. Repeat until a viable solution to the problem is found or that a solution is feasible.
  6. Set preliminary release time frames or windows based on past development team capacity or based on past performance for similar projects.                                                       Product managers will usually set dates for as late as possible and work backward from those dates to get a rough start date.

Agile Planning meeting

The purpose of the Agile Planning Meeting is to have everyone in the Team achieve a shared understanding of what the problems are, why we need to solve them, the order these need to be solved in, how we might achieve a solution, and making a commitment to delivering an agreed scope to an agreed release time frame.

Planning is used to set initial expectations but then the team constantly updates those expectations throughout the life of the project as the Product Owner and development Team gain new information. The Product Owner and Team should re-access their commitments at the end of each sprint.

The Agile planning session takes the following route, the recommended facilitator is shown in italics for each segment:

  1. Introduction – Chief Product Owner/Scrum Master. Review the Agile planning meeting agenda and how the next 2-3 days will unfold. Emphasize the dynamic, participatory nature of this planning event and the need for speed (not haste) to maintain schedule timing. (15 minutes)
  2. House Rules – Scrum Master. Whole team defines the house rules. This is a exercise to document the expected behaviors and conduct of the planning meeting. (15 minutes)
  3. Business Goals & Vision – Chief Product Owner.  Senior management (CEO, CFO, CTO, COO) will share how solving the customer problems will affect the business tactically and strategically and why it’s important to the business. (15 minutes)
  4. Vision – Chief Product Owner.  Share the vision of solving the customer problems, how these solutions affect the business and product, and why it’s important to the customers. (15 minutes)
  5. Who are the customers – Chief Product Owner.  Talk to customers live or play customer interviews, read through transcripts. The goal is to get every to feel the pain the customers are feeling. (60-90 minutes)
  6. Empathy Mapping – Chief Product Owner.                                          Develop an Empathy Map of your customers and users. The goal of the exercise is to create a degree of empathy for the person. UXD and Product Management will probably have personas but Empathy Maps are specific to the project Goals and the current problems. (15 minutes)
  7. User Journeys-what will be different – UXD.  User journeys old and new. How the product needs to change to allow for new user journeys. Do this for each of the customers and users identified during the Empathy Mapping segment.  (15 minutes)
  8. Speedboat & Anchors – Scrum Master.                                          Identify what’s standing in the way of your goals and vision. Identify what propels the team forward, things we need to continue doing and those things that slow the team down, blind spots in our processes, and in general, things that prevent us from being more successful. (15 minutes)
  9. Trade-Off Sliders – Scrum Master.                                      An up front determination by the team of, when push comes to shove, whether you are going to be able to flex on scope (preferred) or whether you’ve got wiggle room around the date. Watch the expressions of people when development wants to trade schedule for quality. (15 minutes)
  10. What’s In, What’s Not – Chief Product Owner.                                            Saying what you are not going to do is powerful. It eliminates a lot of up-front waste by letting the development team focus on items that are IN while ignoring everything that is OUT. It is from the IN column that all high-level user stories will flow. The group also identifies those items that are questionable. These might be some nice to haves but are not as important as those items in the IN column. (30 minutes)
  11. Story Mapping Goals, Users, High Level Tasks, and sub-tasks – Scrum Master. The priority of Goals and High-Level tasks are shown left to right with the highest priorities to the left. As a group order the Goals first. Then do the High-Level tasks and align these with the users. Expect the order of Goals and High-level tasks to change once they’re visible on the wall. The Chief Product Owner, Product Owners, UXD people, development team will start top down mapping in progressively greater detail down to the sub-tasks necessary to achieve the goal. The sub-tasks will generally become the User Stories and the High Level tasks will become Epics. Expect a lot of trade-offs, compromises, and debate. The back and forth through the Story Map will continue until a consensus is reached that it makes sense and is achievable based on current knowledge and understanding. See the Story Mapping Guide and Jeff Patton’s Story Mapping for more details. (1 – 3 days)
  12. Estimation and Adjustment –Scrum Master. In the previous step, the team allocated all the work to releases. Now the development team needs to go through and estimate the tasks & sub-tasks (suggest using T-Shirt sizes, XS, S, M, L, XL, XXL) in order to calculate the actual number of sprints needed for each release. Trade-offs and compromises will occur as work gets shuffled based on earlier release time frame calculations made during pre-planning activities. (1 hour)
  13. What will it take – Scrum Master. The entire team will revisit the Speedboat & Anchors chart making any new additions. The team will now review those items, especially anchors, that potentially put the plan at risk. The team will put together whatever action plans are needed to reduce or eliminate critical risks. (30 minutes)
  14. Report plan to the executives – Chief Product Owner. The development team reports the results of the Agile planning session to the executive managers and answers any of their questions. If management doesn’t already know, the development team needs to make them aware that all estimates and dates are based on current knowledge. The Chief Product Owner will summarize the value of each planned release and what the customers can expect.
  15. Closing – Scrum Master. Overview of the achievements made by the team during the course of the Agile planning session. A few highlights, crazy moments, and key outcomes including release dates. Senior management, Chief Product Owner, and Scrum Masters stand and congratulate the team for their time and efforts. People are given the rest of the day off and sprint planning for the first sprint starts first thing the next day.

 

 

Author: Robert Boyd

I’m a CSP (Certified Scrum Professional), CSM (Certified ScrumMaster), and CSPO (Certified Scrum Product Owner). For 30 years I’ve been streamlining processes and systems. I’ve introduced agile methodologies to software and product management departments, resulting in a 300 percent increase in feature deliveries.

Leave a Reply

Your email address will not be published.