Scrum Sprint Planning (and Capacity Planning) in Squad teams
Hello,
At my organisation, we are using Scrum for our Squad teams (composed of back-end engineers, mobile android, mobile iOS, QA engineers, Product Manager and a TPM). To support Scrum in this setup, we are doing the following:
- As the roles are not interchangeable (a QA cannot to a back-end work, and a back-end cannot do a mobile work), during the sprint planning we have to do plan the capacity at a role level (backend, mobile android, mobile iOS, QA). To support this, we are requesting the engineer to create backend, mobile android, and mobile iOS implementation tasks under the user-story and estimate them with the engineer (we have a engineering tasking session between the Grooming and Planning for the engineers to discuss the technicalities and estimate together).
- The vast majority of time, we are having the development of a user-story in Sprint 1, and then QA done in Sprint 2 (once back-end and mobile work is completed, and dev testing has been performed). During the Sprint Planning, we are very careful about which task supporting the user-story are being picked up. Instead of tracking the user-story spill over, we are tracking the implementation task spill over.
While this approach works, it requires quite a lot of overhead from the TPM (acting as Scrum Master to some extend), to ensure that the tasks have been created, the right tasks are being picked in the sprint (e.g. Dev tasks taken during the sprint and QA task will be taken in the following one), and it is error prone. This can be partially attributed to the tooling (i.e. no easy / automated way to do that in Jira).
I would love to hear how other companies are using Scrum with a cross-functional squad.
Thank you
The way it has been solved in the organizations to which I have been associated was to throw away tasks. Instead the team was focused on getting something describing a change to the product that provided value to the stakeholder done within a Sprint timebox. Since the developers meet every day for the Daily Scrum where they planned their work for the coming day based upon work done and new information learned previously, the tasks aren't really necessary. In fact, going to the detail of individual tasks is actually wasteful and inhibits the developers abilities to adapt to changes. Don't plan a Sprint based upon whether everyone has 8 hours (or whatever measure you use) of work each day. Plan it on whether what the developers have pulled from the Product Backlog into the Sprint Backlog will provide enough value to the stakeholders to justify the effort.
In any organization I was associated to where tasks were used effectively, they were created by the developers every day during the Daily Scrum and it was because they were scattered across world-wide time zones and they felt it helped them coordinate and communicate. Any other uses of tasks were ineffective and wasteful.
If you are able to create such a detailed plan ahead of the work being executed, you might be doing more harm than good trying to use Scrum.
It seems the effort is made in the name of Scrum implementation in you company is only to setup cross-functional teams and to follow fixed time sprint. But the attribute of those are missed. A cross-functional team should self-manage their work/decisions, For eg., They should decide if adding task is needed if it helps them. So there is no one required to oversee them. And a cross-functional team is formed to work on a common goal in a sprint. Having the development done in 1 sprint and testing in other looks like you just have them sit nearby and call them as 1 team, but nothing else changed from their traditional approach to work. There is no "Done" increment at end of each sprint that can be used/reviewed.And there is no real improvements identified by the team.
You can think of trying different sprint length to create an increment within a sprint. Or you can even consider following Kanban approach if it helps better for your team.