Planning Software Product - The Agile Way
Tips from the Trenches

Your company (a startup, small company, or a division of a larger company) decided to build a new software product. You are in charge. What’s your first move?

Naturally (of course!), you would want to use Agile best practices to manage the process. But ask yourself — do you have enough information to begin? Where would you start? May be start with user stories?

While Agile excels at building software, such processes as companywide product planning and coordination are not directly addressed in the methodology.

As a result, “simple” questions like “How long will it take to build the product” or “What functionality will be implemented in Release 1” often answered by long explanation on how Agile works without providing specifics needed for other branches of the company. Which of course is not particularly helpful for Marketing and Sales as they prepare for product marketing campaigns and launch!

Here’s approach that worked for me in the past to ease at least some of these challenges.

The idea is to start the new product development with the lightweight Planning phase (Agile Product Planning). This phase is dedicated to achieving the following main goals:

• Ensuring different parts of the company is on the same page early in the cycle in terms of the product direction and expected functionality
• Formulating product vision to ensure all follow up decisions are made with this vision in mind
• Outlining constraints such as business milestones and resourcing to ensure appropriate scoping and prioritization

Once the product planning is completed the regular Agile process can start with user stories breakdown, UX work, and technical design/development.

Let’s dig deeper into the Planning phase.

To make product planning more reliable it is generally a good idea to start by forming a virtual Product Planning team. The team ideally should include representatives from various departments (think Sales, Marketing, Development, and IT working together!).

Try to keep the team small — no more than 6 team members. Oh, and do not forget the Scrum Master — somebody who will coordinate the team’s planning effort.

Once the team is formed, the planning can start.

Here are the main points the Product Planning Team should address.

1. What specific problem(s) the product will solve?

Without clear and specific single sentence answer to this question you may have trouble explaining the product value to stakeholders, clients, to your own team, and to yourself!

Remember — you need to excite people about the new product, and having a good answer to this question is a great first step.

2. Who will buy the product?

A good answer to this question is extremely important for 3 reasons:

• It forces the team to think beyond the technological coolness of your solution
• It allows your business to start targeting future product buyers in parallel with product development.
• It may affect release scope and prioritization if the product users are not the same as product buyers (something that’s quite possible in enterprise scenarios).

3. Who will use the product?

Knowing who your users are (including their roles) will help you later on with much higher quality user stories. On the business side it will drive marketing and sales targeting.

Remember that buyers and users are not always the same — it is important to understand both.

4. What are the milestones?

Often product must be completed before a well known business deadline, such as a conference where you’d like to announce it, a meeting with investors, a launch by your competitors, etc. Knowing the deadline ahead of time might influence how user stories are prioritized to ensure high quality delivery for that date.

5. Release 1 Functional Outline

Before Product team starts working on user stories, it is important to write down (and accept within Product Planning Team!) a high level Functional Outline of the first version of the product — something you can easily share with stakeholders and customers, and something that sets a common ground for the product within the company.

The outline does not need to be extensive (couple of paragraphs or several bullet points should do it). If written well, it will translate almost directly sentence-by-sentence to user stories later on.

6. Release 1 Estimate

This point is to some extent anti-Agile in nature, however in many cases it cannot be avoided in real life.

Guess what will be the first question from stakeholders once the product functionality is understood. If you guessed “When is it going to be ready” — you are right!

Unfortunately in some cases the estimate is required even before user stories are written and estimated by the development team.

To understand a magnitude of work ahead, it is generally good idea to include “Rough Order of Magnitude” estimate (ROM) in your planning cycle. ROM estimate assumes very low precision (+- 50%), but it still provides high level understanding of the product development effort: are we talking weeks, months, or years to deliver the product.

The typical practice to come up with ROM estimate:

• Use Release 1 Functional Outline as a starting point.
• Ask your development team how long it would take them to develop such solution. To make things interesting feel free to cap the time for this answer to 30 mins
• Multiply the number developers provided by the “Team Optimism Level” (developers tend to underestimate effort 2–3 times in most cases)

The resulting number is the ROM estimate you can share with stakeholders.

Important note — ensure you make it very clear (in writing!) the estimates are preliminary and actual development may take longer or shorter depending on specifics and complexity of the requirements.

7. Beyond Release 1

Understanding what lies beyond Release 1 will help with technical decisions your team making and will reduce future refactoring. Having couple of paragraphs or several bullet points describing post-Release 1 product direction should be sufficient at this stage.

Later on it could be converted to full scale Product Roadmap!

8. Define Technology Stack

Now when developers understand the high level requirements as well as the time constraints, they can come up with a technology stack that fits the requirements and the team expertise.

9. Resourcing

Knowing the ROM estimates, deadlines, and technology stack allows to plan development resources required to deliver the product.

That’s it!

The whole process of planning may take from several hours to several days, depending on the complexity of the new product, how well the product idea is formulated, and how aligned the team members are.

It is generally good idea to use agile prioritization techniques to avoid an impasse between the Product Planning team members. See my article on Ideas Prioritization — Agile Approach as one of such examples.

Smooth Agile development process from this point on!

Written by Alex Apollonsky CTO at OysterLabs

Originally Published on Medium.com