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.
More tips on how to identify real-life examples of Epics and break them down into their components can be found in the GSD Blog.
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.
A great exercise to get your team into the agile mindset is what we affectionately call the I’m Late for Work game. To play the game, give everyone their own stack of sticky notes. Ask them to write down all the tasks that they perform from the moment they wake up in the morning until the time they leave the house to go to work.
When everyone is finished, draw a timeline across the top of the board that starts with Wake Up and ends with Leave for Work. Go round robin around the room and ask people to put up their sticky notes of tasks in sequence. The next person adds only unique tasks to the timeline until every unique task is on the board. You’ll be amazed at how many tasks people perform in the morning.
Now, draw that same Wake Up / Leave for Work timeline on the bottom of the board. Tell the team that their alarm did not go off this morning and they only have 15 minutes to get ready for work. Together, they must decide which tasks are mandatory, so they can be prepared for work and still leave on time. For example, will taking a shower, putting on makeup or eating breakfast make the cut when they are late for work?
The late for work set of tasks is the team’s MVP for their morning routine. If your team only has a limited time, say 90 days, to deliver a fully functional application, your team must go through the same process in release planning.
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.
< Back to Chapter 1 The Team —– Chapter 3 Story Writing >
Want your very own pdf copy of the handbook?
Click Buy Now and we’ll email you a copy for 50% off the Amazon cover price.