It all starts with "give me the number".
When I’m working on a product with my client, we tend to ask each other a gazillion of questions, although the most common ones are:
- How much will it cost?
- How much functionality is good enough to enter the market and not fall short of potential users’ minimal expectations
- Will we make money out of this product?
- Will people use the product?
And there is no way that a Product Manager can get away without having solid answers or at least assumptions to the above questions. Why? For many various reasons, but the most important one is:
- Will the business case be successful?
Answering this question is a path through a complex process of calculations, assumptions, and number crunching in general. The topic is too large to cover it in one blog post, therefore I will focus on one coefficient which can often kill a business case - namely development work estimations.
Those who have something to do with software development, are familiar with the following story:
- "Hey, here is my backlog… how much?"
- "Just give me the number"
With the new endeavour, it is indeed a challenge. And the way we approach it at Objectivity is as follows: we take the mix of team members (Technical Architect, Business Analyst, Developer, Tester) and perform an estimation session. Different methods are being used (Story points, Man Days, etc.), and the outcome is the number (with many assumptions).
- "Ok, that will be X millions"
- Whoa, that is way too much! What if we take this and that away?
- Let me get back to you…
If the last sentence is your most frequent answer, I assume that this is because, at this point, you feel uncomfortable to make any changes in a precisely calculated proposal. Any change - oh, there is no way you can trust your numbers, and therefore you have to recalculate it all once again. If so, then you might make great use of the method I am proposing, so keep on reading…
Carmakers to the rescue
The more I work with the clients, the more I see the need for bespoke customization, budget tailored solution, and maximization of value for money. Wouldn't it be cool if the experience of deciding what goes into development was more like buying a new car? You might think that buying a car is much simpler than software projects (yeah…). Actually, throughout my work at Objectivity I have come up with a solution that allows me to have such an experience, and it has nothing to do with boring excel. How? We'll get to the main course soon, but before that – a little starter first.
I am a big fan of Azure DevOps for product backlog management. It's not perfect, it has some drawbacks, but out of all the softwares I have worked with (Trello, JIRA, Redmine, etc.), it delivers the highest value for money in my humble opinion. It can be used for tiny projects, but also for monstrous ones. I remember one which easily reached 300k items and it kept going even after I left - that includes tasks, bugs, tests cases, user stories and anything that can be tracked.
Someday, I thought that it would be super cool if I could have a real-time view of what is going on with the backlog during estimation and beyond it. Our Project Managers produce reports and that is fine for them, yet for me, as a Lead Business Analyst/Product Owner, it was not enough. Certainly, it was not enough for product planning. So, I played around with queries and that led me to … Excel …. Nothing close to cool. Unless you are a fullstack Excel developer, then there could be some ...
Then, I found it is possible to build custom dashboards directly in Azure DevOps… very simple ones, based on queries and… again disappointment…
Finally, I stumbled upon Power BI connector to Azure DevOps. After setting everything up as per Microsoft Docs (you will find detailed steps here), I was able to mine all the data related to my product backlog. And that was a small Eureka moment, as my intuition whispered to my ear: thas might be super extra cool.
It was. And I will present it based on estimation process since that was my first target.
Power BI with Azure DevOps journey through estimations
What I mostly like about DevOps is the fact that you can build a hierarchy of your product. As a standard, it is configured to consist of Epics
- User Stories
- User Stories
Such a structure, when used correctly, allows amazing visibility of what has to be done and what has been done at the later stage.
Depending on the kind of people I am talking to, it is no surprise, that C-Level people talk on the Epic level, whereas developers' interest is at the User story level and below.
There is a bit of a conflict because estimations happen mostly at the User Story Level. When speaking to top management this is too detailed, so some kind of aggregation is required. It seems simple, but none of the tools I have mentioned deliver such aggregation in a user-friendly way (if at all).
Having full access to the backlog data, I created a report which contains all Epics, Features and User stories together with their estimations. Using some DAX transformation formula (see at the end of this post) I was able to build an aggregator which works.
Not impressed? Then add some filters to the mix.
Now, you might probably be asking: why going so far just to get what excel does pretty well. Filtering by row is by far one of its oldest functionalities. And you’ve caught me here… probably you are right that in the case of the existing backlog, it would be a waste of time to go such an extra mile just to filter the backlog. Aggregation? Also simple stuff with some basic formulas. So why Power BI? Because it is cool!
And the real reason? Excel is good at here and now (snapshot) and only in the case of a stable environment. If you live in such an environment - congratulations, you don't need an alternative.
On the contrary, I have the following conversations on a daily basis:
- "Ok, that will be X million"
- Whoa, that is way too much! What if we take this Android and iOS mobile app away?
- Let me get back to you…[Click] That will be Y
- Hmm, so if we keep Android app?
- [Click] that is Z
- Let's keep Android then and prove if it works. Oh, btw, that epic seems large, lets drill down to it. Hmm, this feature … I thought it was easy to do, why is this so expensive?
- That is because we have to …
- You know what, let’s remove that, it brings little value for the price
- [2 hours later]
- So how much now?
- [Click] X'
- Superb, that makes perfect sense for my budget now.
So, when you add to the mix the fact that you change assumptions, re-estimate some items, split, create remove … how easy is that in excel? It is nowhere near simple and efficient.
Of course, building a Power BI report isn't the only thing I had to do to keep the dialogue with clients, as presented above. There are a few process adjustments needed, which do not require additional effort from the team. However, they have to be taken care of. These are, for example:
- Backlog has to be atomic. That means items are as much independent from one another as possible.
- Backlog has to be kept in a tree-like structure, which I admire because having a list of more than 10 User stories makes me lose the track of what is where hence grouping into features makes it easy for the eye. For large projects, it is possible to configure items that would group epics (i.e. modules). But that is for the product planning part. Sprint work is always a flat list, so working with hierarchical structure is fully transparent to dev team.
- If estimating in Story Points, Dev Ops already has the field to capture such value. However, if you want to estimate in Man Days, then you need to add such a field for any estimations you might want to use. To take it to the extreme, for the ease of resources planning, you might want to estimate each User Story Man Days based on the role, i.e.
- Backend Developer
- Front end developer
- iOS developer
- Android developer
I have a feeling that building products is more and more challenging these days. The most common problems within software delivery that I face on a daily basis are:
- Too short time frame
- Too little budget
- Too large scope
Ideas are not equal. Some build upon what has already been delivered, and more often than not, an extension is much cheaper than building something from scratch. Knowing the cost is a fundamental part of the decision-making process. By transforming the problem so that it is close to the process of buying a new car, a product owner or manager can make a better decision. And if you follow my method, there are multiple benefits… at the estimation process, you already created a backlog which, once approved, can go immediately to development. However, the biggest advantage is that you can easily track work versus estimates… but this topic might be covered in a separate post.