Calculating project forecasts in Jira

Question

As a Scrum Master, I want to help my Product Owner to make an educated guess of when features in a project will be implemented, in order to communicate with stakeholders so that they can manage Scope. Leading to priorities and a release plan forecast.

One way to forecast is to create a backlog of Epics and User Stories and ask the team to give a high-level guesstimates in story points. For example with a Swimlane sizing technique. Then populate the Jira estimation field with these values. After some sprints you could use the Release burndown or Version report to forecast dates when certain features might be completed.

But as Jira only has single Estimation field I am afraid when this fields is already populated this will influence the developer estimations during the Sprint planning meetings, certainly because the initial project estimates might not really size relatively to what we using during our Sprints.

Rather I would like to do:

• Create a high-level guesstimate in T-Shirt sizes (not Story Points)
• Create around two Sprints worth of detailed Story Points estimated Backlog
• Use the velocity of the previous Sprints to calculate how much high-level estimates we can process to give a forecast
• Update guesstimates during Backlog Refinement sessions.
• Preferable automate this with the Jira Version Report

Now my question:

• Do you have a setup like this working in Jira and how did you implement this?
• Do you have a better alternative plan for giving project forecasts in Jira?
• Could we use something else instead of Jira to give these forecasts?

Answer 1

Overall it seems that you are on track. Remember The Scrum Guide:

The Development Team is responsible for all estimates.

Allow the Development Team to create the high-level estimates. Therefore the field can be used as intended.

Answer 2

Accordingly to McConnell ("Software Estimation"), T-shirt sizing is helpful to help product team to prioritize things in backlog, because the sizing let them understand priority of a feature basing on its size and value relation. So, you can use it for this purpose. And you can create a custom field for it, and even hide it from developers after it's moved across workflow, if you will (though, IMHO, it will not "anchor" developers so much as you are afraid of).

But to produce numeric estimates in order to forecast completing dates, you need to have numeric estimates given by developers indeed, like guys are advising.

Answer 3

The Version Reportis per board, so if you have more the one board, it will produce a different estimation for each board. So I would consider this approach only when the project uses a single board. The same applies to Release Burn-down Report. I don't think both reports produce a consistent result when there is more than one board. The release (field) is not board-specific, but such reports will depend on the board.

The way you want to provide the forecast is bottom-up, based on estimating the epics and stories. I think the referred report might work only when there is one board per project which is a simple case. Jira should provide a better set of reports with a higher level of customization in order to have some useful tools to predict the future (forecast). The existing reports are difficult to understand with no customization and not valid for a project working with more than one board.

Another workaround would be to estimate the entire backlog using any estimation technique, it could be assigning story points and then instead of keeping the issues in the backlog, ask the team when they expect to deliver them and then to assign to future sprints. Now we have the work planned. Exporting from Jira the information into an Excel file, and then we will have a plan based on the sprint work future planned. This is a possible workaround to predict the future and make some capacity analysis based on resource planning and to identify possible gaps.

I don't see the point of using a different field for estimating at the end as part of grooming activities the estimations become more precise as we know more about the story/epic to implement. The estimation is an iterative process, where the sort term is more precise than the future.

For Nex-Gen Jira Project there a new feature: Roadmap, but it is not available for classic projects. Selecting next-gen or classic project has advantages and disadvantages. For example, you have roadmap for Next-gen, but then you don't sub-tasks for example and other limitations too.

Using a roadmap will provide top-down planning as it should be. For a classic project, the only equivalent solution is purchasing a plugin from Jira Market place, for example, Easy Agile User Story Map for Jira or any other plugins such Jira Portfolio or Big Project that provide some similar solutions.

Jira basic version provides limited options to do a forecast. Jira follows the Agile/Scrum principles where the only way to predict the future is through delivering a piece of software and showing to the stakeholders the work done in a demo session. Reports are intended just for internal use of the team, but not for other audience such as external stakeholders.

I would like to give you a more optimistic answer, but I don´t think the current Jira version (at least for Jira Cloud, the one I know), does not provide a simple way to this forecast estimation.

Answer 4

I'd argue that you don't want to ". . . help my Product Owner to make an educated guess of when features in a project will be implemented, in order to communicate with stakeholders so that they can manage Scope."

Projections are only useful when they carry confidence estimates that are tight enough to be used for planning.

Based on my experience, your product owner needs to know:

• What features are in the current release? (Done, delivered, expected to be reliable; if they are not, that is technical debt and we need to have a conversation.)
• What features are in development (next release)? High confidence that they will be delivered on time. (because that is what the whole team agreed to, and if that changes, you will alert the product owner promptly)
• What features are in planning? What features didn't make the cut for this sprint but are likely to be in the next. This is a low confidence estimate, and should not be used to program resources or sell product, this is just an informed guess.
• What features are in the backlog and are unlikely to be part of this sprint or the next? This is not a promise, but can help people to do planning. If I know that feature X is not part of development or planning, then I can develop workarounds, or plan my work to avoid relying on that feature.