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; } } }

Best approach working with Jira Scrum in a cross functional team

Jimmy M

Hi,

We are a team of mostly developers, but also have a QA team and a Design team. Recently we've been using Kanban in Jira, but have had problems with estimation and scheduling using this approach when the project(s) grew, so are looking into Scrum now.

When we previously used Scrum we never defined user stories, only epics and tasks to describe the requirements. Tasks could be either an engineering task or a design task. When a task was completed QA verified based on the defined requirements. The problem we had with this was that QA team were not accounted for during the estimation, so many times QA didn't have enough time to finish testing during the sprint. The design team was also working outside the sprint in their separate Kanban board.

We are now looking into making use of stories and acceptance criteria to more closely follow the scrum approach to allow us to work more smoothly together and plan work better. I've however been struggling finding the best practices for how to involve cross functional teams in the Jira Scrum approach and have some questions..

1. If we have a story, e.g. "As a first time user, I should be able to create an account so I can do X". This story could consist of:

Acceptance criteria (be done before sprint start by PO and stakeholder(s) review)
Design deliverables (design)
Code implementation (eng)
Functional testing (qa)

Since a story is expected to finish within one sprint, does that mean all the above work needs to finish during the sprint? Previously, when we used "Tasks", we allowed for e.g. design task to be planned in one sprint and in the next one we could do implementation and testing.

Since design work usually involves research, iterations, etc it feels like it's better suitable for a separate workflow outside the engineering sprint. But this feels contradictory to best practices for stories where everything should be done inside the sprint.

2. If you plan for all functions to work on stories how do you handle lead/lag time? E.g. before design is ready what would frontend developers work on, or when design has been finished for the stories what do the design team do for the remainder of the sprint? Previously, when using tasks we would be able to plan work for the full sprint since there was no lead/lag time for the planned tasks since design work was done before tasks were planned in the engineering sprint.

3. Alternatively, the story could transformed into an epic, e.g. "As a first time user, I should be able to create an account so I can do X". This epic can then be broken down into multiple stories/tasks, and e.g. the UX/VD could be part of first sprint and the user stories implementing it part of 2nd sprint? But this feels like a work-around, since part of the story has technically already been completed in a previous sprint.

TLDR. I'm struggling to understand how stories and sprints can be used in cross-functional teams in an efficient way without introducing downtime for the different functions in the team.

Accepted answers

kevin_mcnamee

The software development process consists of two parts: Product Discovery and Product Development & Delivery. These go hand-in-hand as Jeff Patton writes in Dual Track Development.

Kanban is a tool which will help you manage the second part by a) providing visibility, b) maintaining the flow of work and c) managing the priority. The Discovery process is used to break down the feature into smaller and smaller pieces until you find valuable right-sized user stories (INVEST) that you can add to your Kanban board.

The discovery process is a creative process that does not fit naturally on the Kanban board (or in Scrum). Ideas are still being explored so the scope is not yet clearly defined. There are other tools that you can use instead to capture the design process such as User Story Mapping.

So to answer your questions:

1) Firstly, defining the design deliverables and acceptance criteria are part of the discovery process used to create the right-sized user stories. The Kanban board can be used to define columns for each team that is working on the story (visualise before deciding to reorganise).
Secondly, start with managing the flow of work with Kanban and INVEST. Use a simple rule-of-thumb for story-size, i.e. 3-5 days. Wait with applying Scrum and using Sprints, you may find you do not need them.

2) This is why design is not part of the sprint. The design (discovery) process should aim to feed the development machine (Kanban board) with valuable user stories. Aim to create a backlog (Todo column) of 2 stories/developer that the developers can pull off the board. Use the Three Amigos as the final handshake between the designers and the development team before promoting the stories to Todo.

3) Yes, this is not a good idea. We use Epics as simple containers for related User Stories.

Once you separate out the dynamic design/discovery phase from the well-defined development phase (which is visualised on the Kanban board), then you will be better able to judge how big the team should be and which development/test/ops competencies are needed.

I hope you find this information useful.

/Kevin

For more musings on Agile see my blog http://www.softwaresuperglue.com/

All comments

kevin_mcnamee

The software development process consists of two parts: Product Discovery and Product Development & Delivery. These go hand-in-hand as Jeff Patton writes in Dual Track Development.

So to answer your questions:

3) Yes, this is not a good idea. We use Epics as simple containers for related User Stories.

I hope you find this information useful.

/Kevin

For more musings on Agile see my blog http://www.softwaresuperglue.com/

Devany Cocco

This resolves the design process which can be very lengthy and hard to estimate, but it does not resolve having a separate QA team. The lag mentioned in #2 will still happen when there is more than one team with separate responsibilities which be done in sequence.

Devany Cocco

We have the same issue. The product team is managing design and QA work. The product owner is doing all design, the QAs all testing and test case writing. One of the 3 tends to be the bottleneck and work will back up. At the beginning of a large project it is the design, then it will be development, then as bugs emerge, it is the QA team.

The design work and test cases can be added as tasks and planned in sprints before the new features are to be developed. Sprints seem unable to accommodate when a QA team which is weeks behind. The developers did their work, the new feature is stuck mid-workflow and cannot be marked as resolved for the sprint. If the work is put back into the backlog by removing the sprint, the QA will have to hunt to find it. If the resolution is added to the middle of the workflow, the Jira will not be in a sprint for the QA team. This also causes developers to not be invested in resolving bugs and completing deployment.

I believe the answer is that this process is not Agile at all, so sprints are like a square peg in a round hole. But, we're asking if Jira can have something like two workflows and 2 different sprints for the two different teams? Or if Jira should automatically be created for testing in a new project to do this?

The best solution I've found is keeping the Kanban, but ensuring that the flow is quicker by having Jiras automatically assign to the correct users (via project role) when possible.

kevin_mcnamee

Yes, having two or more teams working in sequence creates lag, this is part of a well-known phenomenon in the Theory of Constraints. If you are interested in knowing more about this, I highly recommend reading the The Goal by Eliyahu Goldratt.

Also, handovers between teams usually results in (large) batches of work being handed over, which exacerbates the lag problem. But regardless of whether testing is happening in-team or by a separate QA team, the only way to reduce lag is to work in smaller batches. Ideally we want the team working on one story at a time.

Nataletta

Hello Kevin,

Would you be able to conatct me

Trank you

kevin_mcnamee

Hi Devany,

There are some good rules of thumb that I use when coaching the teams on good Kanban practice. One of these is that the tickets on the board represent the team’s work and what can be delivered by the team. In other words, it should not contain work that is the responsibility of people outside the team (and so cannot prioritise).

Here is a possible solution:

Since the design and QA work is done by different teams, then having separate tickets for this work makes sense (but the handover problem remains). To hold it all together, the tickets should be grouped using Epics. Put the Epics on a separate Kanban board, these can have a status/column per team (design, development, testing), creating a macro flow of work across the teams.

Each team can then have their own Kanban board for their tickets in the Epic. I recommend a common workflow if possible where some states can be specific per team, and configure the Kanban board to only use those states that are relevant to a specific team. (The alternative is creating dedicated workflows, which would also mean creating dedicated issue types, which I don't recommend.)

Since you are using the same project for both teams, you will need to filter tickets for each Kanban board in some way in order to exclude the other team's tickets from your backlog. Either use labels or a dedicated field for this and configure the Kanban filter accordingly.

With this setup, each team can create a sprint and move their tickets to Done, and so reach their sprint goal. But both teams can use the Epic Kanban as a common view of the combined progress to see which Epics are stuck in design or testing.

If bugs are found, then they can be added to the Epic and so the Epic will remain in testing until all tickets are resolved. In other words, the Epic Kanban board creates common cause, since it will be visible that it is the developers will be the ones blocking the Epic if they don't fix the bugs.

Cheers,
Kevin

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-cloud

kanban

scrum

sprint

development

story

quality-assurance

design