How a Data Team Reaches Velocity, Part 2 - The Sprint Process

As you continue looking for ways to maximize team velocity, having the right sprint process coupled with efficient tools like Jira can lead you to success faster than ever before. I know what you are thinking…another Product Manager talking about sprints and the magic of Jira. But trust me, the sprint process is a game-changer in achieving team velocity. After years of experience in technology and witnessing the evolution from waterfall to various agile methodologies like Scrum, Kanban, XP, and FDD, I finally found a sprint process that works wonders for me and the teams I manage. By reducing interruptions and meetings, you too can achieve velocity. Let’s dive into the Data Solutions Team sprint process at Slickdeals .

Two-Week Sprints for Efficient Planning. The ability to plan two weeks ahead with proper preparation allows us to work several weeks to months ahead on strategic goals.

Our example two week sprint schedule:

• Monday, 02 October (Morning): Sprint Review, Retrospective & Demo (previous sprint conclusion)
• Monday, 02 October (Afternoon): Sprint Planning Session (New sprint begins)
• Tuesday, 03 October till 13 October: Daily standups
• Thursday, 05 October: Backlog Refinement
• Thursday, 12 October: Backlog Refinement
• Monday, 16 October (Morning): Sprint Review, Retrospective & Demo (current sprint conclusion)
• Monday, 16 October (Afternoon): Sprint Planning Session (New sprint begins)

Backlog Refinement

In Backlog Refinement, product and engineering review the prioritized backlog set by business stakeholders throughout the quarter, along with tickets that came in through the support queue. We assign the starting sprint for each body of work, allowing developers to prepare for the upcoming sprint planning session. Before, everyone on the team was invited to this meeting but we streamlined the process by removing the engineering team and making the engineering lead optional. Greg Mabrito, Director of Data Analytics, and I would go through the backlog and reach out to the engineering lead if we had clarifying questions which gave the data team an hour back of focus time. As we continued to refine this process by meticulously planning sprints and maintaining a well-ordered backlog based on the priority of work, we observed a reduced need for full-hour refinement meetings. In fact, some weeks, we find that we don't require a refinement meeting at all. This optimization has contributed to a more efficient workflow and improved productivity within our data team.

Sprint Planning

Sprint Planning focuses on reviewing each developer's assigned tickets to ensure they are achievable within the two week sprint. We make adjustments based on ticket complexity and estimates, which we measure in story points. These points represent the effort required to complete a task and we assign work using the Fibonacci sequence. In our experience, a skilled engineer can handle at least 10 story points within a two-week sprint if their capacity allocation is maxed out at 100%. However, this is never the case as we try to accommodate unforeseen disruptions by setting the engineers’ capacity at approximately 70%, reserving room for urgent data requests and KTLO issues. Additionally, we appoint a support on-call developer to manage data support requests, ensuring they work at 50% capacity in the sprint. Also, no ticket should exceed 5 points. If a task is estimated higher, it's broken down into smaller chunks.

Daily Standup

The Daily Standup is a quick check in with the sprint team. The purpose is to discuss what we did yesterday, what we’re doing today, and address any blockers. On the Data Solutions team, we have a fun tradition: we conclude every standup by saying 'Gooooooo Teammmmmmm.'

Sprint Review/Demos/Retrospective

Our sprint review is internal as we conduct external demos separately for the rest of the org (more on that in another post).

The Retrospective helps us understand as a team what went well, what went wrong, what could be done better, and add any team shoutouts.

The Results

By implementing this two-week sprint process, we witnessed fewer meetings and interruptions which boosted sprint velocity. Planning ahead and maintaining focus on specific tasks allowed engineers the freedom to bring in additional items if their assigned work was completed. Our burndown charts finally resembled actual burndowns instead of flat lines.