Aha! Roadmaps | Release dates and feature capacity

If your team has trouble meeting the release dates you've committed to, the problem likely has to do with ineffective planning. In this article, we are going to look at tactics to estimate the amount of effort your release's features will take.

We recommend a combination of feature prioritization and high-level estimation. Having two separate phases leads to more predictable outcomes.

Click any of the following links to skip ahead:

• Feature prioritization

• High-level "ballpark" estimates

• Development estimates

• When dates change

Feature prioritization

Prioritizing features is always optimal, but it becomes crucial when a release has too many features to meet its target date. Use the Aha! product value scorecard to rate each feature against a set of metrics that can define a record's value across the product development lifecycle:

The default scorecard equation in your Aha! account uses the product value score, developed with value-based product development in mind. Each scorecard metric covers an aspect of work estimation that most product teams need to consider:

• Population: How many customers will this item impact?

• Need: How important is it for those who require it?

• Strategy: How closely connected is this work to your company and product strategy?

• Effort: How much work will it take to build?

• Confidence: What is your level of confidence in each score above?

These metrics combine into a scorecard equation that weights each of the first four metrics equally, and applies a confidence multiplier, like this:

( 1.0 * Population + 1.0 * Need + 1.0 * Strategy - 1.0 * Effort ) * Confidence

If you ever want to weight certain metrics more heavily than others, you could easily change the default 1.0 to 2.0 (and so forth) in the equation.

Then, get prioritizing! You can do this feature-by-feature by opening up one record at a time and adjusting its scorecard. Or you can do it in aggregate with the features prioritization page. From this page you can stack-rank or score a group of features that you select. Then save your view — and even send feature rank to external tools like Jira and Azure DevOps.

Top

High-level ballpark estimates

To communicate delays early or manage release tradeoffs, it's important to know whether all of the features will fit into a release. High-level estimates assure teams that a planned release is attainable. Estimates don't have to be perfect, just within your ballpark. To get this high-level estimate, we suggest working directly with a development lead or manager. Use capacity planning for individuals to ensure that the best features are included and your release date stays on track.

Enable capacity planning for individuals in Settings ⚙️ Workspace Configure. You will need to be a workspace owner to do this.

Top

Development estimates

Release dates are not officially set until your development team refines feature estimates to ensure that any adjustments can be made. This step typically happens within engineering and the tool that engineering uses for their work (e.g. Jira). Since agile teams focus on one sprint at a time, this makes high-level estimation even more crucial when a release must be communicated to the rest of the non-technical organization. For this reason, you can also use external release dates in Aha! Roadmaps to roll them up to a week, month, quarter, half-year, or year.

Some integrations, like Jira, automatically send estimate updates from the development system to Aha! Roadmaps records.

Top

When dates change

Some changes to release dates are unavoidable, but most teams want to learn from these experiences. Aha! Roadmaps provides several visual views of your roadmap that you can track changes against. Just add them to an Aha! Roadmaps presentation at the beginning of each release as a snapshot and then an additional page as live view. This will let you see the difference between the original plan and today.

The Releases Gantt view tracks release phases, milestones, feature dates, and dependencies across your entire portfolio. The Releases Details Progress view provides a visual burn-down chart to see what has been added or removed and how quickly work (features and requirements) has been completed.

You can use the Change view type dropdown to switch between the burndown chart and several common views while retaining any filters you have added.

Filters you add yourself will transfer to a new view. Page filters — filters associated with the original view that cannot be removed — will not appear on the new view.

Your View type options are:

• Gantt: The Gantt chart view of your work.

• Details: The details view of your work.

• Progress: The burndown chart of a specific release.

• Calendar: The calendar view of your work.

This process works in organizations that use both traditional and agile software development methodologies. Scoring and estimating capacity at a high level before sending features over to engineering ensures that you know what's needed to deliver each release. This also leads to fewer delays, trade-offs, and unseen surprises.

Top