Launching an MVP for a new product takes a ton of focus at the team level. We're working with a lot of uncertainty — time is often lost on frivolous investigation and/or rushed, non-optimal decisions.
This article is dedicated to our experience setting up productivity metrics and using them to configure a predictable working process.
There’s no perfect tool that will save you from problems with your product. But tracking those productivity metrics is really about being involved and visualising what’s going on — and once you see unwanted changes, take action.
Visualise your product development plan
When we work on an MVP, usually we have a strict budget and a corresponding delivery date based on the scope & the team’s velocity.
📖 By team’s velocity we mean the amount of work a team can tackle during a single iteration. Velocity i measured in story points, hours or any other units applied in the team.
- To make a detailed plan for the phase I recommend using the Gantt chart based on the scope from the very beginning — use the story level to make it more detailed and assign recourses to produce a realistic delivery date.
Check out gantter.com — this is the tool I’m using.
- Don’t forget about the focus factor → instead of using an 8-hr working day for planning purposes, an optimistic value would be a 6-hr working day.
Moreover, based on our experience and considering meetings / additional tasks, a realistic value would be around a 4-5-hr working day (on the product features).
📖 By focus factor, or focus time, we mean periods of time that an individual can focus on a single specific activity — in our case features with clear customer value. It is nearly impossible to reach 100% of your workday dedicated to the product features — we have meetings, syncs, investigations and so on.
So for initial planning, we assume that 6 out of 8 workday hours would be dedicated to working on product features.
- Once you have a detailed Gantt chart, go one level higher and prepare a roadmap for the whole team on the epic level.
It is an open question whether you need to go and update your detailed Gantt chart on a regular basis. For short development phases (1-2 months) updating the epic level roadmap every 2 weeks should be enough.
MVP plan and budget tracking
Every week’s iteration ideally should finish with delivering a working piece of increment, a feature with a clear customer value that could be tried out.
There is an opinion that tracking % of the work done in comparison to the planned scope might not reflect the real situation — as just one feature may change it completely and require significantly more or less time.
So focus on the budget here — track the budget usage and the corresponding completion of the scope, to make sure we are not falling off the plan/budget ratio.
📖 To calculate the % of MVP scope completed, we take the hours or story points originally estimated, providing a ratio of all planned and completed features.
Measure team productivity metrics
The scope & budget state is already a good presentation of the team’s work. But to have data for our improvements and dig a bit deeper into how and why we deliver at this pace, we also calculate:
- Sprints plan / fact stats
Using these stats we want to see how well we stick to what we plan from sprint to sprint. This data may be of great use for retrospectives to discuss what activities take the time we need and plan for features, and how we could minimise it.
- Real team’s focus factor
Out of 8 hours in a standard working day, how much do we actually spend on product features? With time we replace the “Real” capacity from the previous metrics with the one calculated based on the team’s focus factor.
- Team’s energy level
Team morale is a good metric to track which isn’t about the work itself but rather about the team being excited about what we do and how we work together. I usually ask the team members about their energy levels at the end of the retrospective (every 2 weeks).
Build forecasts
As discussed at the beginning of the article, working within a strict budget means that we have a deadline when the money will run out. So in addition to the metrics above, I usually calculate the estimated delivery date — this is something that is easier to communicate to the team & founders.
I have 2 approaches for delivery date estimation: pessimistic and optimistic.
The first one is based on the completed % of scope. We take the % and the number of sprints we had to cover it → and calculate how many we will need to cover 100%.
This value might be not accurate due to the fact that we consider only features that are completed. Those that are in progress don’t count — but in fact, the scope remaining would be smaller due to those “in progress” features.
The second approach is based on the team’s velocity. We know how many story points or hours we cover every sprint, and we know the total amount of story points or hours — so we could estimate the total number of sprints.
The downside of this approach is that it doesn’t consider features that took or will take longer than initially estimated.
The combination of these 2 approaches works really nicely providing the delta and giving founders a realistic picture of MVP development pace.
Well, choose the one metric or a combination of them that feels right and valuable for your product, and start!
We often talk about improvements, but keep in mind that no improvement is possible without initial data — as it is the starting point we evolve from.
.svg)
