Chapter 2 – GSD Gold Project Planning

****

The GSD Gold Approach to Project Planning

Throw out the old notion that you must know all the details about your project in order to plan and execute to the plan. The real world is not that black and white. It’s a traditional waterfall PM’s worse nightmare!

The traditional project management triangle constrains your project by Time, Scope and Budget. What we’ve found is that in the real world, most project managers start with an approved budget, team and deadlines. So, Budget and Time are generally fixed. This situation is perfect for agile scrum, because you cannot accurately predict what you will deliver at the start of the project.

How Do GSD Gold Teams plan with Agility?

  • Plan for Feature releases
  • Deliver the Minimum Viable Product (MVP) first
  • Focus on near-term deliverables
  • Pivot after stakeholders use the application

Stop thinking about work breakdown structures and Microsoft Project Plans.

Start thinking about delivering on release milestones.

Identify Application Epics

It is the Product Owner’s responsibility to help the team understand what needs to be built as part of the project scope. The Scrum Master brings the Development Team together with the Product Owner. The Product Owner lists the high-level features or groups of related functionality that must be delivered to meet your given deadlines. Each high-level feature becomes an agile scrum Epic.

For example, suppose you are building an online banking application.

Epics could include:

  • Customer Login
  • Customer Account Maintenance
  • Customer Account Display
  • Customer Bill Pay
  • Customer Statements
  • Customer Balance Transfers

When you’ve exhausted the list of Epics, it’s time to break down each Epic into its components.

Break Epics Down Into GSD Components

Pick a different color sticky note or ink color for each feature or Epic. Use sticky notes to break down each Epic into smaller components, without worrying about priority or release dates.

A GSD component is a unique part of the feature set that can be delivered as standalone functionality. For our object-oriented or UML friends, think of a GSD component as a use case.

A component breakdown of the Customer Account Maintenance could include:

  • New Customer Enters Required Data
  • Customer Updates Personal Information
  • Bank Updates Customer Account Balances
  • Bank Updates Customer Product Offers

When you can no longer think of any new components, it’s time to define the Minimum Viable Product or MVP for the first release.

Minimum Viable Product (MVP)

How do you decide what to deliver first? In agile, we have the concept of Minimum Viable Product or MVP. The MVP is the bare bones application the team can deliver to stakeholders and they can use the application as intended.

In reality, the Minimum Viable Product or MVP has a slightly different meaning. The MVP is a prototype that only includes skeleton features for customers to validate the application’s usefulness and to authorize further development. The MVP product is typically deployed and demoed to a core set of customers, who understand the vision for the end product and can provide meaningful feedback. This helps the team avoid building application features that the customer really does not want.

What the agile community often calls the MVP is actually the Minimum Business Increment (MBI) or the Minimum Marketable Feature (MMF) set. The MBI is the smallest piece of functionality that has meaning to your customers.

For purposes of this handbook, we will continue to call the bare bones application the MVP. The important takeaway here is the need to determine:

What do my customers consider as the highest priority components for each feature?

When you know this, you know what components to build first. The Product Owner and the Business Analyst meet with your customers and review the most-used business to identify these high priority components. Think about applying to Pareto’s 80/20 rule to the application feature set.

Create the Release Plan

Now that you have all the component sticky notes on the board under each Epic, review the Epics and components with the Product Owner and decide what components comprise the MVP for your stakeholders.

Group components that should be delivered together (they can reach across feature sets) and let the Product Owner prioritize them for delivery. Rework the groups of components, so the team feels comfortable delivering them by the release dates assigned to the team. You now have an agile release plan!

Even with continuous delivery to production, you should still plan to deliver a completed set of feature components by a given release date. Yes, strict agile purists say, “We’ll get it done when it gets done,” but most of us live in a corporate world where we must show progress against a plan and be able to report whether or not we are on track to deliver on our timelines. In the real world, if we want to get paid, we have to deliver commitments that line up against strategic roadmaps.

Focus on Near-Term Deliverables

As we stated earlier, agile is not the Wild West. Once you know the features that you want to deliver, engage your architect or tech lead to create a high-level design or architecture roadmap for your application with approval from your Product Owner.

Now that you have release schedule, does that mean the team has to spec out every single component before they begin development? No, it doesn’t. Focus on the requirements for the next couple of sprints, because those are the deliverables the team will be coding.

What’s a sprint? A sprint is a short-term, fixed development cycle that generally runs from 2-4 weeks. For the sake of this discussion and because we believe 2 week sprints are optimum for most development teams, let’s assume the team works on a 2 week sprint cycle.

Doesn’t that take the pressure off, knowing that you only need to write detailed requirements or stories for the next 2-4 weeks? We explain how to write excellent stories in our next post. For now, we want you to change your mindset to focus on the near-term, so you can get stuff done now that helps you clarify the requirements for later deliverables.

Move to Production and Pivot

With agile scrum, the team delivers potentially deployable code at the end of every sprint. This is great news for you, since now the team has the option to continuously move to production. Frequent moves to production demonstrate progress and give those paying the bills the opportunity to use the application and to continually see team progress.

This also allows for quick course correction instead of building against requirements that are 6 months to a year old. When your stakeholders have a chance to dive into the application, this reduces overall project risk. The feedback, “You built what I said, but that’s not what I want” conversation occurs early in the project, while there’s time to pivot, update your Epics and still deliver on schedule.