Today, I'd like to share some of the ideas and estimation approaches that helped us in past
projects. The tricky part in long and short-term planning is how to predict the unknowns that
will influence us in the future. As I wrote earlier, there are several things that usually come
up and may not be visible in the product backlog when you are planning something.
In projects related to mobile app development, we usually encounter the following unplanned
- Defect fixing
- Backlog refinement activities
- Collaboration on UI/UX design
- New user stories
Defect fixing is quite obvious and we have spoken about it already. You can't usually foresee
what bugs will appear.
Backlog refinement activities include understanding the backlog items, analyzing the underlying
technical and usability aspects, and making the backlog items meet the definition of ready.
The UI/UX design process is not just a simple decision about colors and shapes. The controls used
and the screen layouts and flows usually have a large impact on how the application needs to be
built, and we witness over and over again that a seemingly small aspect of the design idea can
have a vast impact on the complexity of the actual implementation. So in order to keep the
cost/benefit ratio reasonable, we have learned that it is necessary that the developers
collaborate closely with the designers in order to prevent any unpleasant surprises. You can
read more about this topic in this
Refactoring existing code and infrastructure setup is a must if we want to develop a product that
will be sustainable for longer than a few weeks. It can also have the potential of making the
dev team more effective.
New user stories are interesting. You invest a lot of time into the backlog refinement and it
just looks perfect, everything is thought through and sorted. Fast forward two months into the
future and you discover (with new knowledge from that past two months) that you need to simplify
some stories while others have become obsolete, but more importantly, you realize that you need
to introduce completely new features that are vital for app's meaningfulness. You couldn’t see
this before you had the actual chance to play around with the features from the past couple of
months and gather feedback from users, analyze the usage stats or see the economical
Having most of the stuff in the backlog estimated for its complexity (size) is vital for any
planning. But as we have all probably learned the hard way, estimates are almost always anything
but precise. We, therefore, did not find any value in trying to produce exact estimate values
(like 13.5 man-days of work), but we rather use the approach of relative estimation while using
pseudo-Fibonacci numbers: 0, 1, 2, 3, 5, 8, 13, 20, 40, 100.
It is important to understand that these are dimensionless numbers. They are not hours, man-days,
or anything similar. It is an abstract number used solely to set a benchmark and compare other
items against each other.
So what does that mean? At the beginning of the project we pick an item in the backlog that seems
to be of a common size and appears neither small nor big, a number between the 5-8 range. That
will be our benchmark and all other stories are then compared to it. How much more difficult (or
easy) is this or that item compared to our benchmark?
Over time, we usually found out that the initial benchmarks and estimates were completely off.
But that is OK, it's a learning process. It is important to review the estimates after the
actual development and from them. Was that user story really an 8? Were these two items as
similar as we initially thought? If not, how would we estimate them now and why? That also means
that from time to time it's necessary to revisit all the already estimated items in the product
It usually is not necessary to go into deep details with stuff that is several sprints ahead. As
the team gains experience with the product domain, the developer's gut feelings get more
relevant and precise. That means useful estimates can be done quite swiftly after the team
grasps the particular feature's idea. Sure, some stuff in the backlog will be somewhat
underestimated, some overestimated. But with long-term planning and predictions it usually
suffices because statistically, the average usually gets quite reliable.
The outcome of all this is a backlog where every item is labelled with its size. It becomes clear
what items are meaningfully defined. The development team has an idea about the technical
solution (meaning that the size is reasonable) and what items are completely vague or for which
the team members lack key business or technical information. Those are usually the items with
estimates labels of “40”, “100”, or even “??”.
If such inestimable stories are buried in the lower parts of the backlog and the product owner
does not even plan to bring them to the market for a long time from now, that's fine. But do any
of these items have a high value for the product and do we want to bring it to the market soon?
If that's the case, it sends a clear message to the product owner: back to the drawing board,
let's completely re-think and simplify such user stories and expect that some team capacity may
be needed for technical research.
So after all this hassle, the upper parts of the backlog will have numbers that you can do math
Quantifying unexpected work
The last piece of the puzzle requiring predictions and plans is to quantify how much of the
unexpected stuff usually happens. Now, this might seem like a catch-22 situation - how can we
predict the amount of something that we can't predict by its definition? At the beginning of the
development, this is indeed impossible to solve. But as always, agile development is empirically
oriented - over time we can find ways to get an idea about what is ahead based on past
experience. As always, I am not preaching any universal truth. I am just sharing an experience
that my colleagues and I have gathered over time and we find useful. So do we do it?
It's vital to visualize any team's work in the product and sprint backlog as transparently as
possible. So it's also good to include all the stuff that are not user stories, but the team
knowingly needs to put some effort into them (like the known regressions, researches,
refactorings, etc.) into the backlog too. If it's possible to estimate the size upfront, let's
do it. If it's not, either cap the maximum capacity to be invested or re-visit and size the item
after it's been done. This is necessary in order to gather statistics.
Just to be clear - let's not mistake such unexpected work with a scope creep. I assume that we
don't suffer from excessive scope creep, the unexpected work is indeed solely highly valuable
and necessary work that was just not discovered upfront.
So now we have a reasonably transparent backlog, containing the originally planned stories and
also the on-the-go incoming items. We have most of it labelled with sizes. In the next part of
this series, we'll try to make some statistics and conclusions on top of all this.