A reporting is a target group oriented presentation of information.
An optimal reporting …
… should
- be easy to handle,
- be easy to understand but informative>
- be available when needed and easy to access,
- ideally real-time information and
- informative to the respective target audience!
Presentation of an implemented reporting system
| application: | eshop |
| teams: | 8 Scrum Teams |
| methods: | Scrum und SAFe |
| ticketingsystem: | Atlassian Jira + Structure |
| Number of structure levels: | 3 - requirements AND epics AND (stories, tasks, bugs) |
Requirements hierarchy
There are small, medium, large and really large requirements.
For a small requirement, that only takes a few days to implement, it is usually sufficient to formulate it in the form of a story or a task. It doesn’t really make sense to forcefully subordinate a small requirement to an epic – a superordinate bracket.
The individual tasks of a medium-sized requirement, which may have to be implemented by several developers and which are too extensive for implementation within a sprint, can be bundled together as „related“ via an epic. The epic therefore forms the bracket for logically related tasks.
Epic as milestones
Large and really large requirementn often have a scope that makes it necessary to implement them step by step over several milestones (= intermediate goals). These individual milestones would then be named in the form of epics.
It is important that these epics are not just a division of the work into part 1, part 2, part 3, etc. but, if possible, represent self-contained milestones that, if at all possible, represent added value on their own.
Requirements documentation and ticketing
(Jira) tickets are used exclusively for task management and not for documenting requirements.
Example: recommended action for the PO:
The Product Owner meets the Sales Manager for a stakeholder small talk over a coffee. The sales manager tells him about an interesting functionality that a customer would like to have implemented. A lively conversation ensues.
Immediately after the small talk, the product owner creates a JIRA ticket of the type Requirement and a Confluence page and links them to each other. The title of the Confluence page and the summary of the Jira ticket reflect the requirement in a concise and comprehensible form.
The product owner captures the requirements on the Confluence page and shares with the Sales Manager, the Sales Manager reviews the Confluence page and adds clarity and supplementary information as needed.
Once the „what is needed“ is reasonably clear, the product owner involves other subject matter experts to discuss „how could the requirement be implemented“. Developers, UX’ers, etc.
It slowly becomes obvious that the requirement is a real monster in terms of the expected implementation effort. The product owner, in collaboration with the other experts, defines milestones (= interim goals) in order to be able to deliver initial results as quickly as possible. These milestones are stored in the form of epics, all of which are linked to the requirement ticket. The requirement represents the „parent“.
As soon as an epic / milestone is sufficiently well specified and the product owner wants to see it implemented soon, the developers can start breaking down the epic / milestone into stories and / or tasks. The sum of the estimated efforts of the stories and tasks of an epic determine whether the milestone can be implemented in a release / PI or whether it would make sense to split this milestone /-this epic – further.
Epics, stories and tasks have their content documented in Confluence; this context is linked to the corresponding JIRA ticket. In Confluence a list of “in scope” and “out of scope” is maintained to ensure that the right thing is implemented.
Reporting
Management is generally less interested in the individual stories and tasks, but is normally interested in the milestones and the requirements themselves. For this reason, the summaries of these two hierarchy levels should be formulated clearly and comprehensively.
If we assume that milestones/epics are normally completed within a quarter/PI, then that is the cadence we should reporting at. As a manager, I wouldn’t be interested in the minutiae of the story and task level. If a large requirement – stored in Jira as a requirement – may also have a long life cycle, this (requirement) may not really be suitable for reporting. If a large requirement has several or even many milestones, the requirement may remain in the „In Development“ status for a longer period of time.
Example::
A requirement could, for example, be „reduction of material consumption“ or „reduction of energy consumption“ and both could be achieved via various measures, which in turn are achieved as (hopefully clearly formulated) milestones. Each milestone (= epic) should be able to be implemented within a quarter / release / PI and the tasks to be implemented are then subordinate to the respective epic.
Or: Optimization of the vehicle cockpit user interface. This could also be an overarching goal that is stored above the epic level in the form of a ticket and to which various epics (= milestones) are then subordinated.
It is important that both the higher-level requirements and the epics (= milestones) are formulated in a way that is understandable for the authorized addressees of the respective reporting. We have often come across summaries with customers where even the product owner no longer knew what they meant two weeks later.
It is important that both the higher-level Requirements and the Epics (= milestones) are formulated in a way that is understandable for the authorized addressees of the respective reporting. We have often come across summaries with customers where even the product owner no longer knew what they meant two weeks later.
JIRA Automation
Implemented Logics:
- If a story or task is assigned to an epic and the epic in question is still in the “To Do” column, it is automatically moved to the “In Refinement” column.
- As soon as the first story or task of the epic is in an active sprint, the epic is moved to the “In Development” column.
- As soon as all subordinate issues have the status DONE, the epic is moved to the DONE column.
The higher-level tickets, the requirements, are handled in the same way.
- As soon as one of the subordinate epics leaves the “To Do” column, the requirement is moved to an “In progress” column.
- Etc.
By using JIRA Automation, it is easy to keep the reporting up to date. Whenever a manager – e.g. the product manager – looks at the epic board and perhaps focuses on the priority 1 epics first, he/she will see the status quo of the most important milestones. If the cards on the epic board are well configured, the epics can also be assigned to the higher-level goals or requirements.
Conclusion
Through structure and comprehensibly formulated summaries – at least at epic level and the level(s) above – it is possible to create (near) real-time reporting that is easy to understand and easy to handle, which can then be used to call up the status of project execution at any time; and without the need for regular recurring reporting.
Do you need support in implementing such a reporting system?
