Not fully agile progress report in JIRA

I recently came up across a use case and a solution to a problem that I think is quite common among people working in a not fully agile IT project. This article describes the use case, the problem, and a solution with JIRA and the app ALM Structure for JIRA.

The use case

An organization Org that has a project Prj running with "a not fully agile" approach, sometimes also called WaterScrumFall. What does this mean? It means that Prj has a start date, an end date, a defined budget with a high level scope and effort estimation, and of course a team. This sounds much like waterfall doesn't it? The Scrum part is that:

1. The requirements are defined but no detailed design is present up-front
2. The team works with Sprints, with typical Scrum ceremonies (Daily standups, Sprint planning, demo/reviews and retrospectives)
3. The project backlog is defined with n Epics, estimated, and detailed stories will be defined during the projects.

Epics though, are designed according to architectural components, hence quite long lived, in contrast to the best practice of having Epics doable in a few sprints.

The team uses JIRA to define Epics, Stories, development and testing activities.

The problem

The Org management wants a periodic Prj progress report, ideally has a % of progress, but this in itself is not a problem :). The problem is that standard JIRA reports do not allow you to have a quantitative progress report if all the stories are not initially defined and estimated.

Prj would like to be able to show the progress by having the Epics' original estimate be consumed by Stories as they are closed. That is, if Epic1 is estimated to 10days, and we have closed a Story estimated to 1day, then Epic1 progress is 10%. The average progress on all the Epics will show the project progress.

The solution

With the JIRA app "Structure for JIRA", you can create dynamic pages with a defined hierarchy, by taking issues from a project or with a custom JQL. You can therefore show all the Epics, their original estimate, and the Stories under each Epic with their original estimate and status.

What's more interesting is that with Structure you can define a column of type "Formula", that offers you powerful scripting capabilities. With the help of the Structure support, the formula I was looking for is the following:

//Total Original estimate (only Epics)
with total = SUM#ALL{if(issueType = "Epic";OriginalEstimate)}:

//Total Original estimate of all issue types where Status = Closed
with story_done = SUM#all{if(status = "Closed"; originalestimate)}:

//Percentage
with percentage = story_done / total:

//Show the percentage just on levels that has children underneath.
if (count#children{0} != 0;
CONCAT(round(percentage*100), "% complete")))        

The Structure formula documentation is available here.

How does it look like? Below you see an example where Prj has 7 Epics, only one Epic is started with 2 Stories in it of which only one is closed. Summing all the Epics' estimated Prj is estimated at 100 days. Epic1 estimated to 10 days, and Story1.1 (Closed) estimated to 1 day. Hence the Epic1 progress is 10% and Prj progress is 1% (1 day completed out of 100 days estimated).

The column "Formula original estimate" uses a similar approach and it displays the original estimation for the the whole project and "in progress" Epics, but without counting the Stories.

In this example we used the effort (original estimate). One could use Storypoints or Business Value instead with the same approach.

Conclusions

JIRA and its app ecosystem are very powerful. But addressing some edge cases in project reporting can be sometimes challenging as standard reports are for...standard approaches.

Structure for JIRA, with its formula column, is extremely powerful and brings your reporting capabilities beyond the limits of standard JIRA reports.

I hope you found this useful, if you have any questions feel free to let me know.