Agile Project Planning Techniques Overcome Fear of Unknown

We understand there is an overarching desire in project management to know a good amount of detail before project planning takes place. Traditionally, these details are constrained by Time, Scope, and Budget.  It has almost always been my experience that Time and Budget that are fixed.

If two of our three biggest constraints are fixed, then why are we so afraid of project planning? We fear the unknown. This fear of the unknown can range from intimidating to downright scary. The GSD Method of agile scrum offers several techniques to overcoming this fear that keeps us becoming better project planners and accurately predicting what and when we are going to deliver results.

Change the Fundamental Way You Plan Projects

In traditional waterfall project management, we typically get a six month to two year roadmap, and we build out a detailed work breakdown structure with hundreds to thousands of tasks (no joke, I have actually seen a project with 10,000 tasks to plan and track). Then, we go through weeks of scheduling those tasks with the core and extended project team, only to find that about two months into the project, the plan is irrelevant and out of date.

The first step to throw out the notion of traditional waterfall planning and begin thinking in terms of Epics instead of work breakdown structure. What is an Epic you ask?

Think in Terms of Epics

An Epic is a high level feature of a product or application. For purposes of this post, let’s say we want to develop an airline reservations application.

At the start of the project, the Scrum Master brings the Development Team together with the Product  Owner. The Product Owner lists the features (or groups of related functionality) that the customer needs the team to deliver to meet business deadlines. Each feature becomes an Epic.

A few example Epics of our airline reservations project include:

• Customer Login
• Customer Book Airline Reservation
• Customer Search Airline Reservation
• Customer Change Airline Reservation

Decompose the Epics into Components

Once the team identifies the list of Epics to be delivered as part of our project, it is time to break these Epics down into GSD Gold Components. A GSD Gold Component is a unique part of the feature set that can be delivered as standalone, independent functionality. For our object-oriented or UML friends, think of a GSD component as a use case.

We could decompose our Back to our Customer Book Airline Reservation Epic into the following Components:

• Customer searches for available airline flights
• Customer selects flights to book and creates an airline reservation
• Customer pays for airline reservation
• Customer searches previously booked reservations

When the team cannot think of any new Components for all Epics in the project, it is time to start thinking about the MVP (Minimal Viable Product) and scheduling release milestones.  

Define the MVP and Delivery Roadmap

The Product Owner and the Business Analyst (if you are lucky enough to have one on your scrum team) meet with your customers and identify the highest priority components that provide the most value and should be delivered first. If the team has 90 days to deliver a fully functioning airline reservations application, a full review of all the Epics and related decomposed Components should be reviewed and prioritized.

The following steps help identify the MVP:

1. Group Components that should be delivered together (these definitely can reach across Epic feature sets)
2. Prioritize Component groups for delivery and decide release dates
3. Rework the Component groups until the team feels comfortable delivering by the release dates assigned to the team

Viola! We now have an agile release plan that, in the real  world, lines up against strategic roadmaps and that the team feels comfortable delivering.

Focus on Near-Term Deliverables

Agile is not an excuse for cowboy coding. Once you know the Epic features your team plans to deliver, have your architect or tech lead create a high level design or architecture roadmap for your application.

Now, it is time to start focusing on near-term deliverables. We’re not talking about breaking down every Component into a detailed plan, we’re talking about focusing on what we need to accomplish in the next 2-4 weeks or the next two 2-week Sprints. A Sprint is a time-boxed development cycle. Our Sprint preference is 2 weeks, as we believe this is optimum for most development teams.

To get ready for the team’s first Sprint, the Product Owner and Business Analyst further break down the highest priority Components into Stories. In agile scrum, Stories are the requirements and quality assurance acceptance criteria that make up what need be delivered.

You don’t have to write every Story for every Component, only those Stories that must be delivered in the next 2-4 weeks. How awesome is it that? The first two sprints set the pace or velocity of the project, give the team something to demo so the customer can validate their requirements, allow the team time to pivot if requirements change and ensure the team has the confidence to deliver on schedule.

For more information, check out:

Chapter 2 in our GSD Scrum Handbook: GSD Gold Project Planning 

Chapter 3 in our GSD Scrum Handbook: GSD Gold Story Writing

Happy planning,

April Shepherd

April Shepherd
AprilS@gsd.guru  503.307.9072