How to build a good Jira Board
Jira. It’s the wonderful agile tool that teams use to keep track of what they’re supposed to do. If there’s anything I’ve learned while being the Jira Administrator of a group of 300 people is that there are many ways Jira can be used and abused by product managers, team leaders and product owners. In the last year I’ve helped restructure 20+ projects and helped teams fix both insignificant and show-stopping mistakes in their Jira practices. In this post I will mention some of the biggest mistakes made when creating a Jira board for your own group. Of course, always look at the requirements of your project or customer before implementing any of these.
Not knowing the difference between Kanban vs Scrum
The word ‘Kanban’ means something like ‘Visual Cards’. If you imagine a factory, the idea is that you can tag all in the process so you know how many items are in a specific place in the factory. Since the factory has a set beginning and a set end, the Jira Kanban board will have a set beginning and a set end. Useful if you have a lot of products that need to go through the same process.
- Document Approval Flows
- Delivering software to production without a CI/CD Pipeline
- Identified and non-changing wants from customer
Scrum uses some aspects of ‘Kanban’ but is different in the fact that it uses Sprints. These are time-periods of 2 to 4 weeks wherein you agree to work on a block of work with your team. After the initial period, you come together to talk about how you can improve the process and start a new period of 2 to 4 weeks. This change can be seen in the Jira Scrum Board via the Product Backlog. Here you can prioritize and select the items you want to work in during a sprint. Scrum is excellent for software development since it’s allows for a great amount of feedback loops that allow the team to self-correct.
- Scrum Teams / Software Development
- Project-leader with a team (The scrum board works surprisingly well with a Gantt-chart if you use this ‘top-down’ approach)
- Complex and changing wants from customer
Note: If you want to have a Jira Scrum Board you need – at a bare minimum – a person in charge of prioritization (‘Product Owner’/’Project Leader’) and a realignment session that you have every 2 to 4 weeks.
Using Description rather than ‘What, Why, How’
Trim the fat. Delete everything from your Jira card that you don’t need. Version, links, reporter, date created, components, fix versions, affected versions etc can be deleted (unless your team really requires those of course!)
What you’re left with are the basics: Just add the ‘What, Why and How’. It’s easier, cleaner, less intimidating. You can even print these out and have all the text on one side of the paper.
Not using (Story) Swimlanes
You can select swimlanes if you want to structure stories on your Scrum Board. By swimlaning based on ‘Stories’, you get a nice detailed view for every story (and subtasks) on your board. Just make sure every story has at least one subtask!
Of course, there are some other selections you can make, but most people I worked with find this view the most organized looking. If your team doesn’t like sub-tasks you can also decide to swimlane based on Epics.
Not using Epics
Write Epics as if they are user stories that you can complete. If you don’t you’ll eventually end up with a large amount of old Epics that you need to scroll through in order to get to a story. Either use features (‘Once I can do <A> this Epic is done’) or time (‘This Epic will be closed at end Q4 2017’) so that they remain fresh. Only use Epics without an end if they run through until the end of the entire project.
Adding Users rather than Groups
Please don’t delete the ‘administrators’ group from the permission list. And please don’t add people on there manually. Ask an admin to add them to the appropriate group.
Not making your board public
If your Stakeholders aren’t sitting next to you in the room, make sure you publicize your Jira board. Stakeholders should have read-only rights to your Jira Board and Product Backlog. The Product Owner should show the boards during his conversations with the Stakeholders.
Having more types than Epic, Story or Subtask
Unless required, stick with Epics, Stories & Sub-tasks. Everything else will clutter up the boards. Of course, if your team really likes the ‘Bug’ story and uses it – go right ahead. The goal is to have an effective amount of options by selecting the smallest amount of highest-used ones. You can leave the tasks, features, improvements, impediments for when you really need ‘m.
That’s it, let me know what you think about it. Again, this is based on my experiences in the company. It would probably be different in other companies, so be sure to mix & match until you have a way of working that works for you!