nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

New agile boards

Ryan O Sullivan

I am switching to the new boards from the classic boards , and it is a hell of a mind set change, i think i am making progress , however the question i have is how fix versions relate to sprints now.

it seem a sprint can contain issues that have loads of different fix versions.

are the sprints totally disconnected from the fix versions?

if so how do developers know what to check in changes against?

at the end of the sprint how do you demo the changes if there are multipler different versions

Accepted answers

Chris Hodgens1

Sorry for taking so long to get back. Been on a business trip.

We use story points for estimating stories, technical debts and support stories. We say 3 points per day and have sprints of approx 2 weeks giving us 30 points per resource per sprint. This is what we use to estimate how much work can be done in a sprint. We started doing this as we initially were using hours to estimate but soon realised that the time did not bubble up to the story on the boards and that we did not really want to estimate time for sprint planning but complexity of task, hence the story points.

We always keep the backlog for the board ordered and the stories etc are estimated with story points when created. For sprint planning this allows us to pretty much take the top of the backlog and add that to a sprint, but to the number of resources available for the 2 week sprint against how many points we are prepared to put in the sprint (We do about 80% capacity on story points to allow for support that always happens). Once we have created the sprint and added the stories, technical debts and support stories etc, then we go through and plan the sprint by adding th subtasks for each of the parent items. Once the planning meeting is over the sprint can start and then work at as much velocity as possible to get that sprint completed.

Regarding why subtasks do not appear on the planning board. The planning board is meant to plan your parent stories, etc. You should have no need to see subtasks at this point. once the sprint is started, then the developers should work in the work board and there they work through the stories by dragging the subtasks left to right until all the work is done.

There are many ways of skinning the cat, so to speak, but this is the way we use it and found it works well.

All comments

Chris Hodgens1

The way we use it, and our mind set is that the sprint is just an intense period of development to try and complete tasks that will be testable. It does not have to end up in a release. We can have multiple sprints before we actually do a release, but after every dev sprint, there is a QA sprint. This allows dev and QA to work at their own speeds, and on completion of QA, gives the release manager the option of creating a release if they desire. Sometimes we may have 3 or 4 sprints before we want to do a release. Because Dev and QA can work at different speeds and are often in different areas, then this allows developers to carry on working at max velocity.

We think of a sprint in terms of a fixed period of time (we use 2 weeks) that we plan what work available resources are going to work on. This means that the resources could be working on different components or different projects, and so would have different versions, but because there is a collective "run" to complete the tasks, then all effort is spent on completing the planned work.

Our developers check-in to main when their tasks are completed, and the main branches are labelled on completion of sprints, so that QA can then pick up the work that was in the completed sprint in their own time. Developers could have continued onto any further number of sprints while QA is going on, but only when QA is completed, are versions released.

Hope that makes sense.

Chris Hodgens1

Yes, took us a little while to get used to it, but it does improve velocity, while quality of releases have also gone up.

Ryan O Sullivan

Thanks Chris

This makes sense as you describe it. It will require a shift in mindset from how we currently work as we treat each sprint as a deliverable piece of software.

the new boards will allow a lot more flexibility however it will also require retraining for QA and Test teams

Ryan O Sullivan

So the sprints no longer show up in the versions associated with the project?

and it's ok to have items in a sprint without a fix version?

Chris Hodgens1

You do not need to have issues in a sprint belonging to a version (You just don't get the version losenge to the right). If you click on the version on the board, the board should filter to only show you the issues that are in that version, be they in the dev sprint, qa sprint or backlog.

Sprints are not project specific. They are linked to issues. So that if you had two boards with issues in different sprints, if the issues showed up on both boards, then you would also get the sprints that the issues were in showing on both boards.

Ryan O Sullivan

Hi Chris

I am working with the boards now, in the classic boards i did estimates against the sub tasks (technical tasks ) associated with the story, these then agrregated up to the story level, while this still works in jira , to me the JIRA agile boards see the estimate against the story as zero , and the sub tasks have theor own estimates.