17 Feb
Photo by Tirachard Kumtanom from Pexels
Similarly to my latest blog about GIGO, today I’d like to describe an approach that I would recommend to take when you’re considering a new requirement requested by stakeholders.
As we know, stakeholders are concerned about the outcome of their investment (not necessarily just ROI, but also other non-measurable benefits) and the cost of execution. Their requirements are usually their high-level expectation, where functionality is described briefly, if at all mentioned. This is a normal occurrence and shows how differently stakeholders view things. That’s why dev teams need – and have – a dedicated person to speak with the client and understand their needs.
So, how can you deal with stakeholders’ demands and use them to deliver high quality, accurate cost estimates? There are a few things to consider. To illustrate, I will use my same old example of the newsletter signup form – a simple potential requirement that is easy to understand. Imagine that we have a platform that is publicly available, and it has a homepage/landing page. Stakeholders decided to add a newsletter signup form to that page, and are asking how much it would cost.
1. Differentiate between functional and nonfunctional requirements
In short, start by considering what will happen “behind the scenes”. Separate what end user will be able to do (fill in and submit the form) and what the system will have to do:
- Process the form
- Go through follow-up actions
- What else?
Separating these two layers of the requirement will create a list of follow-up questions for you to bring back to stakeholders. At the discovery stage you would probably spot most of these questions and ask for the details you need. But sometimes these questions appear later, after you have thought through all possible edge cases (discussed in Step 3 below).
When you have identified all the requirements, you will have a better understanding of what systems changes will have to take place and what team members will be engaged.
2. Think holistically
Once you have identified all the requirements, it’s time to consider the request from a more global perspective. There’s only a minimal chance that any particular requirement would be an isolated feature without any impact on other parts of the platform.
When one module has to speak to and work with another, the cost increases. It may also be the case that other modules must adapt to a new change and need even more upgrades down the road.
In addition, this is a good time for you to expand on the initial requirement and propose a new offer with even more functionalities. You may suggest something that stakeholders did not consider, or something they don’t need at this point in time – either way, it would never hurt to offer a consultative approach.
Going on with our newsletter subscription example, things that are worth considering are:
- What happens after the user successfully submits the form? Maybe they get a thank you email, or a series of emails.
- Where will their email be stored? How will they receive the newsletter? Maybe it’s a case of integrating a third party tool or creating an in-house newsletter mechanism.
- What would be sent and what filters would apply to the emails?
- How would these emails look from a UI perspective, should they match branding?
3. Explore edge cases
This is often the natural next step after the previous point. When considering what modules are affected by a change, there’s usually friction between them, which makes edge cases appear. These edge cases are the biggest cost factor. The more of them you spot, the more accurate your estimation would be.
Following our example, possible edge cases could be:
- When integrating with third parties, what if an email address already exists in the vendor database?
- What if the email address provided by the user already exists in our own database?
- What if, for example, we don’t generate enough content to populate our weekly summary newsletter?
Sometimes the edge cases may have a small or no impact on the cost, but some may impact it significantly, so it’s worth looking into them carefully.
4. Speak with your team
Teamwork makes the dream work. No matter how good you are, you won’t be able to cover all possible cases and think about all the paths that can be taken to deliver the requirements by yourself.
Sure, team meetings can be long and dull, but this can’t be an excuse to not consult with at least the team leaders. To be more efficient, prepare a small summary of the requirements with all your findings about edge cases, possible issues, and the goal. Your experts will help you identify weak spots and suggest what is the size of the workload.
The outcome
Remember to document all the requirements, edge cases and suggested solutions. This documentation will be used by your development and test team while implementing the features, and you will use it when delivering the features or when creating product documentation and help articles. You can also use it in the future when stakeholders come back to you asking for updates or comments.
Keep in mind that practice makes perfect. After using these steps a few times, you won’t even notice that you are following them for your estimations. However, be careful not to get too comfortable in your routine, as it may negatively affect your estimations – it’s important to always review the basics and explore ways to improve.
Piotr Pozniak is the co-founder of The Beaverhead, a business process optimisation company, and the brains behind The Estimation blog. Before establishing The Beaverhead, Piotr worked as a software developer creating high-end products for the aviation industry. He saw how enterprise software is built, what the challenges are and how it works, and he wanted to provide that quality to smaller businesses and entrepreneurs. Over the years, Piotr has worked towards becoming a software cost estimation expert, and today he shares his knowledge through The Estimation blog.
Piotr Pozniak