Is there an example of the BEST way to setup a Jira board (and project) for an agile team?

Jamie Chennells

Everybody uses JIRA slightly differently - I would love to just see an example fo the BEST way to use JIRA so that I can see what I am missing, and techniques I could make use of. 

 

Anyone have any examples or screenshots? All I want is a live demo of populated board Seems impossible to find. 

Nic Brough -Adaptavist-

I keep coming back to think about this one, and not typing anything because it's actually impossible to answer with a demo or best process.

I want to fall back on the basics that there is no best way to set up a Jira for one team that will automatically be best for another.

A simple answer here is that you should choose whether Scrum or Kanban is closest to the way each team wants to work and have the team adopt that methodology. 

One of the things people who have only skimmed the basics of Scrum often miss is that part of the process is improving the process for your team, and that would include customising the tools in use to support them. 

I don't think Kanban says much about self-improvement, but I'd apply it in a Kanban team as well - make sure you have a process that is a regular review what's working, what isn't and what 

In other words, to get the best Jira setup for a team, the most simple thing to do is to create a Scrum project and board off-the-shelf, and get them to do Scrum.  (Or Kanban with a regular "process improvement" thing baked into it)

• You'll probably already  have some stuff that you think you need, like a set of custom fields or an inherited workflow, but do not try to do everything or build too much complexity
• Do add fields, but only ones that are critical for reporting
• Do bring in an existing process as long as you think it is broadly what you want to do, but keep it simple - be clear about what status are to-do, in-progress and done for the team, and most importantly, only include the part of the process that this team can deliver (in cases where you're not Agile and do things like "developers develop, testers test" - the developers can't deliver tests, so their board ends with "ready to test")
• Don't try to be clever with these or over-design them, keep it simple to begin with.

Even the first sprint should uncover stuff you do and do not need, and ways to do stuff better.  Keep looping through the sprints and have your scrum master or team lead remind people that part of the process is improving the process.