When it comes to product development, estimation is considered an art. It is discussed as early as the project brief the client hands over, when we still try to get a sense of what the product is. With every new project and through our Scrum approach, we’ve tried to refine our measurements by formulating some questions to guide our discussions before we take on developing a new software product.
Our premise was to ensure clarity of concept and to answer all the questions that a development team might have later in the process. Here are 16 questions our teams believes are important when discussing the planning of a new software product:
1. What is the goal of the project?
Especially in our Scrum + MVP approach, it is important that we and our client come to a common understanding as to the purpose of each project. The scope is likely to expand or contract as the collaboration progresses due to unforeseen complications. But the purpose remains the same. Is the purpose of the project to test a prototype with users, deliver the core features or attract and grow a new user base? Try to define the goal in SMART way. It forces you to think about it twice.
2. What problem does it solve?
It’s important that you view these questions with an open mind. As logical as it may seem, it’s a question that often goes unsaid in the initial discussions, making it problematic to only ask it when the product is halfway constructed and you’re encountering inconsistencies.
A good software product is solving a problem. What is that problem? Once you understand the reasoning behind the idea, you start to understand also your client or the end user.
3. Who will use it?
Reaching and maintaining a common understanding of the product requirements from the user and the client is essential to delivering a viable product. Many software products try to replicate or simplify human behavior which is never an easy task. We like to review the user’s objectives when using the product to learn as much as possible about them and factor in their reaction to the essential features. User modeling is an excellent exercise to get a better understanding of the users and their needs and drive the product development roadmap.
4. What should the application do?
Use other software products or useful analogies to get a clear image of how the software is intended to be used. The more basic and simple it is expressed, the easier it is to understand where the core functionality is. Only then we can create different scenarios that focus on the essential features of the product.
5. What is the domain we need to understand?
Each industry is leveraging the benefits of technology and the specifics of an industry can have a considerable impact on the software product. In the financial industry we have security, privacy and compliance as key while user experience and open data can be the cornerstone of other industries. The better you understand the industry, the more you know how to create the product and what to consider in estimations.
6. How should a specific feature look like?
As you’re going into more detail, you have to align visions of what a feature should look like so that both the client and the development team have the same overview. Communication should be centered around the User Stories.
7. Keep a clear overview of the features and stories
Remember a Product Backlog is eventually a one dimensional to do list that if it becomes longer easily results in loosing track of what is actually being built. Story mapping is a nice way to have the Stories in a 2 dimensional structure with the features on one axis and the releases or time on the other.
8. What are the specifics of a certain topic/story/feature?
Go into as much detail as you need and avoid assumptions. It’s better to spend more time asking these questions in the beginning than to fix them later.
9. What is the expected workload?
Instead of focusing solely on time, estimate the team’s workload. A user story that requires 6 hours of uninterrupted concentration can take 14 or more when dealing with constant distractions or multi-tasking.
10. Which platforms is it going to be available on?
It is important to know if the client already has a platform for development and deployment. If it is Azure for example, we can consider this platform’s features in development so that scalability / management becomes easier.
11. What other parties integrate with the application?
Integrations can be the cornerstone of a software product so it’s best that you have a relevant idea of how it connects with 3rd party systems from day one. Planning a robust API could be important, even if the first version of the product will not have the API released.
12. What team will develop the product?
A development team is not just about the programmers. Who else will be involved side by side? Is there a product owner already considered, and does he or she has all the information and freedom to take decisions and drive the product forward?
13. What knowledge is needed in the team?
Technical knowledge is implied and should fit the specific requirements of the project. But what specific knowledge related to the project could help the team achieve success? A team developing a Digital-identity solution for example should have access to someone that understands the privacy domain not only from a technical perspective but legal as well.
14. What technologies will be used?
Leverage your existing talent on a certain technology when weighing on this decision. It’s also a question of time involved – different solutions can take more time or less time both in coding time as well as execution speed.
This is a crucial question that will determine the specifics of code maintenance and future support. Will the software product need to be enhanced or expanded? Then you’ll need to ensure the right technology is used that allows maintenance on long term.
15. What’s the timeline for product development?
This affects the team size, which affects communication and how we prepare for ensuring that the average speed of development will be optimal. While there is no strict deadline in Scrum, a product has business constraints. The client needs to go to market and expect to do so within a certain timeframe. If we know it, we can better plan the backlog and advice on how to move forward.
16. What are the constraints in terms of budget, requirements, and priorities?
We understand any client wants all the features possible in the first version of the product. Our focus is to deliver working products, and in doing so we need to discuss what is feasible. Together we need to prioritize the workload so that everyone agrees what the next step is.
