Ebury Jira Masterbook
Introduction
In Ebury we have been using Jira since 2013, and in all these years we have had dozens of changes, new teams, projects, policies, methodologies and Jira versions have come and gone, and how we are using Jira has evolved during this time.
Currently, we do have dozens of teams grouped by areas (FX, Money Flows, Channels, Platform and CRM) using Jira on multiple ways that, if well it is true we have a common core, there are many small details and differences among them which can bring inconsistencies, conflicts and troubles.
Goals
The purpose of this document is to collect all those rules, common for all teams and mandatory in all cases, and guidelines, optional but recommended, that each team must/should follow in order to guarantee an optimal experience using Jira.
This will help teams to work more efficiently, removing doubts and questions, and making the Jira experience smoother so people can focus on their work without struggling too much with Jira.
Additionally, this will also bring many benefits in terms of management, as having common practices will allow us to have common reports instead of having specific ones per team.
It is not expected that this document can work as Jira training or documentation, as it is only covering specific topics related to how Ebury uses Jira.
Rules
-
Allowed project type: the only allowed project type is Company Managed and the associated workflow Ebury Agile Workflow Scheme 2018.
-
Allowed issue types: Epic, Spike, Task, Story, Bug and Release. The support team is also using Incident to track incidents, don’t use it for any other purpose as it has some automations associated.
-
Epic's life cycle should have a beginning and an ending. Currently epics should take less than 3 months. Avoid endless epics in all cases.
-
No issues without epic. In order to facilitate the task categorization needed for the quarter reports it is necessary to always assign an epic to our tasks. In this way, we only need to categorize epics instead of tasks.
-
Cross teams epics not allowed. In line with the previous point, and in order to facilitate reporting, epics cannot be shared across teams.
-
Description is a mandatory field and it should clearly explain the task background and context, what’s the business requirement, the proposed solution and the acceptance criteria (for User Stories).
-
Business description is not a mandatory field but it has to be always filled. It should contain a short and clear explanation in normal English -no complex tech concepts- so everybody can understand. For User Stories this should be filled by the product team. This is the field appearing in the release notification email and, because of that, we should make an extra effort to make it understandable and clear.
-
Fix Version cannot be blank. In those cases where a task is not deployed, like spikes or management tasks, we can choose the no release (NoRelease-Year202X) fix version instead.
-
ERI cannot be blank. Only in those cases where issues have not been resolved but closed a won’t do, duplicated or something similar, or there is no real proof of completion, as for interview tasks, we are allowed to type https://none instead. Check this blueprint for further details: Evidence of Requirements Implementation (ERI)
-
The components field should be filled always, not only for the main services but if there are code changes, we should always track what services those changes are related to.
-
Monitoring plan and deployment notes are mandatory for closing a task. In those cases where they are not really relevant, we can set NA instead.
-
Warranty Engineer is not a mandatory field but it has to be always filled for tasks with a valid fix version before starting the task deployment.
Guidelines
-
For tickets not related to a project/epic, we recommend creating an epic per team, type (Commercial, Compliance & Ops, Running, Sustaining and OH) year and quarter to track them. Example: ODT Running FY21/22 Q3
-
Priorities setting. There are 2 main ways for setting the priority in a sprint. Task priority is great for organizing priorities from a management perspective, but we recommend sorting tasks by priority inside the sprint so the team can know clearly what to pick next.
-
We can use labels to categorize our tasks and help us on reporting them. Apart from the labels for postmortem and bugs, there are no constraints and the teams can use them as needed.
-
Test plan and developer notes are not mandatory for closing a task, however we recommend completing them before the sprint starts so teams can have clarity on what has to be done and tested.
-
Sub tasks. Up to the teams. There are no strong recommendations here, those teams that want to use them can do, for example for tracking certain minor tasks which have to be done as part of a ticket, as documentation, sending an email, tracking defects, etc. However, if those subtasks are big enough or even not aligned with the original requirements, like a considerable refactor or new requirements coming from the ERI approval, they should be handled in their own tasks. Worth to mention there are no reports over those subtasks, so they will not be considered for the performance/productivity reports and there is no point either on assigning them story points.
-
Flagging tasks in Jira is not working especially well, and sometimes it can be hard to know what comment is associated with the impediment making us to flag a task. We would suggest adding a flag icon :flag_on: in the comment.
-
Teams can use sub-tasks for tracking minor tasks directly related to the ticket as long as they are not big enough to be an independent task, in those cases you should be using different tasks as highlighted in this RFC. Examples of sub-tasks: defects or improvements opened in the task, updating a doc or setting up a reminder to take a look at something specific.
-
We have 2 main official poker planning estimation methods in Ebury:
-
Counting 1-2-3 and all together at the same time sharing their points estimation showing the finder to the cam.
-
Counting 1-2-3 and all together at the same time sharing their points estimation writing them in the chat.
-
Additionally, we can also use the Parabol planning poker feature, but it may not always be available.
Another interesting approach is giving 1 point by default to all stories and the team has to challenge that and defend why it should be higher.
- Some teams recommend the usage of swimlanes in the sprint board to split different workstreams. However, it has to be used carefully as you will lose the priority track between tasks in different swimlanes.
Recommended reports
List of reports and dashboards are commonly used and can give important information about the teams:
-
As Jira reports, the sprint burndown and burnup chart are the most useful to track the sprint status, and the control chart for controlling the cycle time and those tasks which are taking too long to be closed.
-
Filter to see the bugs and postmortem actions which are pending in your team. Link (please, do not edit the original one)
-
Filter to see tasks with no epic. Link
-
Process labs: Team KPIs
-
KPI Report used in the KPI review meeting. Link
FAQ
-
Where are these rules coming from? All these rules have not been suddenly created now, but they have been progressively created after many years of tests, experiments, changes, complaints, amendments, etc. The result is a set of rules which are thought to increase the quality (mandatory field forcing developers to think about monitoring plans or helping them to do not forget about filling the ERI), the delivery and performance (cycle time) or the reporting and management effort (no tasks without epics or no cross epics).
-
Why are we requested to fill certain fields even if in most cases we are just writing NA or https//:none? Those are all fields considered important and we are highlighting them and also forcing teams to at least think if they should be filled before closing a task.