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:
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.
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.
For more musings on Agile see my blog http://www.softwaresuperglue.com/
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.
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.
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event