Looking for quick ways to improve your Scrum team and its processes? These two quick tips will show immediate improvements. Tip #1: Make your tasks completable in about a day. As many of you are aware, the Scrum Alliance describes the Product Backlog as “an ordered list of everything that is known to be needed […]
Looking for quick ways to improve your Scrum team and its processes? These two quick tips will show immediate improvements.
As many of you are aware, the Scrum Alliance describes the Product Backlog as “an ordered list of everything that is known to be needed in the product. It is the single source of requirements for any changes to be made to the product.”
The items in the Product Backlog are called Product Backlog Items (PBI’s). Some of you may know these items as stories or user stories. PBI’s are owned by the Product Owner and is a statement of need for the Product.
The Scrum Development Team takes the PBI’s and breaks them down into a series of tasks for them to do to implement the PBI. Typically, this breakdown is done during Sprint Planning.
Thus, in Figure 1 below, we have a Sprint Backlog that shows PBI 1 and its three associated tasks, PBI 2 and its two associated tasks, and PBI 3 with its five associated tasks.
Nothing kills your Sprints more than having a three-day task, then a dev team member says they need two more days on it when day three rolls around. For a two-week sprint, that’s half your sprint on one task and it’s a sprint killer. If you make your tasks accomplishable in about a day, then every day your team’s tasks can be flowing through the task board. If you ever have a task that’s stuck In Progress for more than a day, we know something is wrong. Then, as a team, we can work to unblock that specific task. Thus, we create traction every day through our task board and create a flow through our Sprint Backlog.
On many teams, we see team members assign work to each other during Sprint Planning. My second tip moves away from having the dev team assign work to each other during Sprint Planning. Instead, when a dev team member starts each day, they should synch up with some teammates and pull the next highest priority item on the Sprint Backlog that they can responsibly complete. By doing this, you move away from situations where team members are working in individual silos on their assigned work to a model where the team coordinates on their work and forms better communication, better collaboration, and increased cross-functionality. Plus greater focus to work together to deliver the highest priority items first throughout all their sprints!
A story shared by one of our training students, Christopher Morton, Agile Project Manager for Tesla Government, highlights this point:
“Our problem was simple: every sprint we discovered the most important and valuable work wasn’t getting done and we were consistently short of our velocity goals. We reviewed our process, but the solution didn’t jump out at us. We conducted our sprint planning sessions, we determined the appropriate amount of work, and then we assigned tasks based on the talents of the team. We thought we were being efficient this way, but it turns out we were making a couple of big mistakes.
Our first mistake was assigning tasks to individual developers. By doing so we inadvertently messaged to our team that they needed to get their responsibilities done and the concepts of collaboration and teamwork were secondary. The second mistake was thinking we were doing ourselves favors assigning work to team members based on their ability. This meant we had little cross-training across our different microservices and that whenever a team member was unavailable to complete a task, then it got pushed instead of picked up by another member of the team.
Lucky for us the fix was easy.
All we had to do was allow our team some autonomy to select the work they wanted to tackle throughout the sprint. We didn’t magically come to this conclusion; we held a couple of retros to discuss our problems and home in on our most pressing issue. Assigning tasks arbitrarily at the start of each sprint. The team felt it focused them on their lanes and didn’t allow for them to grow and challenge themselves through the code. So, members were given free rein to select tickets from the sprint backlog that they wanted to work, whether it was something quick and simple they could close before the sprint concluded or a problem they could challenge themselves with earlier in the sprint such as work on an unfamiliar microservice. We found that without directly assigning tasks teamwork and collaboration grew to be emphasized and valued by the team and that the most important work always seemed to get done first. Oh, and we nailed those deadlines that had eluded us before.”
As you can see, these two quick tips are techniques that your teams can quickly implement that will give immediate gains in your team’s ability to effectively deliver high quality product increments every sprint.