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

[Chris Hodgens · Accepted solution]

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.

[Ryan O Sullivan]

Thanks for all of the advice Chris

Currently I am looking to switch to use story points for estimation and use time tracking to cover off support , sub tasks.

I don't think i'll create a support stopry for each sprint.

[Chris Hodgens]

Good stuff!

[Ryan O Sullivan]

Thanks again Chris, your advice has been very valuable

I have started using story popints and time tracking is based on hours.

I just use hours for technical debts and support rather than story points.

Works a charm

[Chris Hodgens]

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.

Is that correct?

also why are the sub tasks not visible in the planning board

Many thanks again

[Chris Hodgens]

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

[Chris Hodgens]

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.

[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?