Estimating work and lining roadmaps constitute some of the most important but confusing parts of product implementation. Most development work tends to be complex (see article on work and frameworks, meaning it is never quite like work before it.
This makes estimations just that: an estimate. An exact timeline for implementation will never be perfectly accurate. So how do you keep products growing, plan for what is next, and get operations work done at the same time?
One way is with Story Points. Story Points are a tool developed in eXtreme Programming (XP) to help teams estimate the complexity of individual tasks during the development cycle (more on that in just a bit).
Tracking these over time gives you a ballpark estimate of how much complexity you can address in a given time frame, and helps project managers prioritize development goals based on available time, team capacity, and complexity.
Why not give dates?
Executives love to have hard and fast delivery dates. Who can blame them? Investors need success metrics and clients want specific features, so delivery should have steady deliverables on a predictable schedule.
This unfortunately stands at odds with the very nature of complex work. Software engineering follows the “make the road by walking it” model: Discovering the unexpected along the way is the modus operandi.
A seemingly simple feature set that turns out to be much more complex than originally thought is an average Wednesday in the development world. Practically, it’s nearly impossible to accurately predict delivery dates, thanks to the significant amount of unknowns between beginning and delivery.
In an effort to overcome inability to deliver exact time predictions, XP introduced Story Points.
On Estimation
Story Points use a fixed scale (fibonacci, doubling, exponential growth, etc.) to label rough complexity rather than time. Normally, the whole team estimates the complexity of individual tickets or features, even if they are just a piece of a larger initiative. A feature estimated as a five, for example, is less complex than something estimated at eight or 13.
Each team sets their own Story Point scale and uses them as an internal estimation tool, meaning no two teams’ points equal another’s. Because these are rough estimates, one story given a complexity of five isn’t necessarily equal to another story also assigned a complexity of five. That means you can’t just swap out any ticket for another without involving the team in the discussion.
Points on this scale help with estimating known and near work. Bigger and more uncertain feature sets also need a bigger and less specific scale. As a result of the general ambiguity and required context of story points, we use a higher level of abstraction. Although aggregates of the story points help get you in the neighborhood, they can’t account for the unknown complexity developers will discover along the way.
Fortunately, product managers in the agile community have developed a whole slew of solutions. T-Shirt scales of S, M, L, and XL offer a familiar scale to compare relative sizes of feature sets to one another.
Another solution tags dollar values representative of their approximate size to force the conversation around priority. This model sets a fixed budget within a time frame and asks stakeholders to spend their “budget” on the features that they want. It emphasizes the opportunity cost of picking one feature over another.
Whether you use dollars, beans, sizes, or scales, separating the complexity of engineering effort from time to delivery allows you to understand the multiple dimensions of software product delivery.
In order to explain the importance of timing and concurrency, we will use the analogy of a backyard grill.
Looking at your grill
When evaluating your team’s capacity both as a weekly snapshot and over the course of a fiscal quarter, you should also consider the dimensions of your “grill”.
How many people are on your team? Do you have multiple teams? What is your release schedule? Don’t consider these as limitations, but more as the parameters for what your team can work on concurrently. You have a certain amount of space on your grill, and product owners get to determine what claims that space.
Spacing
With lots of feature sets coming down the line with varying levels of complexity, some will need to take up more space than others. A huge project might look like a rack of ribs and take up 80% of the available space, while some smaller projects might look like a burger, allowing space for four or five of them at a time.
At most cookouts I have been to, someone only wants to eat hot dogs, no matter what fancy food is on the grill. It may be improper grilling etiquette, but I like to throw those on wherever there is space. Think of your bugs and general operations items as those small items that you pepper in as available. They don’t take up a whole lot of space, but are necessary nonetheless.
You do, however, have a finite amount of space. Whatever you put on the grill takes up space and comes at the opportunity cost of something else that could fill it.
Timing
Knowing your spacing matters a lot. But if you have ever grilled anything, you know that different grillable items take different times to cook. A rack of ribs takes up a lot of space, needs to cook slower, and takes a couple hours to soften up. Fresh pineapple cooks faster than a burger even though it takes up the same amount of space.
In the same way, a project might be something that two people can tackle in a day or something only two people can work on and still take a week. The work itself is multi-dimensional, not just a time spend but also a capacity spend.
And, like grilling a specific type of meat, finishing faster isn’t usually as simple as turning up the heat. Using a fire that’s too hot for too long will leave you with a burnt end product and not enough fuel in reserve to cook the rest of your meal. Similarly, turning up the pressure on your team can leave you with a burnt out team.
Variety
Like building a product, cooking a meal consists of more than just protein. With a slab of ribs, you will want some potatoes, some fruit, maybe some green beans.
While they aren’t the main course and might seem peripheral to the purpose of a grill, they fill an important role in a balanced diet. Similarly, quality of life improvements, engineering-led efforts to address technical debt, and unique offerings are equally necessary to the core value proposition.
They shouldn’t fill the same amount of space or stay on the grill the same amount of time, but are necessary nonetheless. A balanced meal includes a balance of each.
What’s the point?
Analogies only get you so far. They don’t cover every attribute of the situation and they offer limited insight into context. The point is that you have limited space for work, some work takes up more space or time than others, and that as an owner of the product, you have to decide which projects get to claim the available space.
Prioritizing one project over another is hard, oftentimes leading to one or more disappointed stakeholders. Putting one feature set on the grill means there’s not enough room for another.
The best parallel to one course over another in an agile environment exists in the product and sprint goals. Set your goals based on what is the most important item, and stand by the decision.
Picking the direction of your product, understanding your users, and planning your courses to cater to your audience means making hard decisions and standing by them. Put the lid down on your grill and wait for the courses to be ready, all the while talking up the great meal to come. And now you’re cooking with gas!
Looking for someone to help you iron out your product roadmap (or build it for you)? Drop us a line to see how we can help you reach success sooner.
