Managing Agile Scrum Teams

Problem

While Scrum is a wildly effective framework, it can come with overhead that can overwhelm development teams. Can this framework be modified to be more effective and less complicated? Let’s discuss what can be done to create an agile Scrum team.

Solution

Agile Scrum project management frameworks can become challenging and time-consuming. This is often related all the meetings and processes that come with it. Data and Analytics teams need a simple and effective project methodology to follow. This allows them to manage their workloads more easily while also getting their jobs done effectively. These teams seek to understand how they can effectively juggle multiple high-priority customer requests while delivering high-quality solutions at scale. A modified approach could save development teams’ time and cost from needing redundant roles on the teams, setting the teams up for success to deliver value to business stakeholders.

Agile Scrum Framework

The following ‘Scrum Framework’ illustration from Scrum.org defines the components involved in Agile Scrum. The core of this framework is the Scrum team, typically comprised of a development team, a Scrum Master, and a Product Owner. The Product Owner prioritizes tasks based on business value and maintains the product backlog. The Scrum Master ensures adherence to Scrum practices and removes obstacles. And the Development Team is a cross-functional group that self-organizes to deliver product increments. However, a key role is missing from this framework: the team’s manager, who also serves as the technical leader and part of this team.

Scrum Framework detailed scrum framework flow

Scrum includes several recurring events for regular planning, review, and adaptation: Sprint Planning, Daily Scrum (Daily Stand-Up), Sprint Review, and Sprint Retrospective, along with key artifacts to manage work and ensure transparency. When followed as intended across multiple Data and Analytics teams, these events can result in many hours of meetings. Unfortunately, this can result in frustrated development teams. While this Scrum Framework has numerous advantages, it can also bring tremendous overhead with the required roles, ceremonies, and processes.

This article will cover a modified Scrum-based approach that is equally as effective without the massive overhead.

Modified Scrum-Based Approach

For this article, we will assume that we are setting up a Scrum-based structure for three Analytics teams, each with five Developers/Analysts and one Team Manager/Tech Lead. We will also assume that we will use Jira for our customer intake and project management boards. The illustration below shows this high-level structure, which originates from a user entering a request, the ticket being routed to a central queue, and then being directed to the relevant project team that will work on the deliverable.

Servicing Flow high level of ticketing process from user to service board to project board

Traditionally, Scrum would recommend that a Scrum Master and Product Owner be assigned to each of these three teams. However, this creates redundancy between the role of the Team Manager and that of the Scrum Master and Product Owner. Scrum typically recommends three to nine team members for effective communication and collaboration. If team sizes are within this range, they can be as successful with the Team Manager role also being responsible for leading the team as the Scrum Master and Product Owner. This will eliminate the need for six extra roles across the three teams while maintaining the same level of efficiency. With proper training, such as the Certified Scrum Master and Product Owner training from Scrum Alliance and other certified institutions, a Manager can become well-equipped to take on these added responsibilities.

Scrum Events

The overhead for traditional Scrum ceremonies can become overwhelming for development teams. With Sprints typically being between 2-3 weeks, Scrum advises that several events need to occur within this timebox. These include:

  • Daily 15-minute Standup
  • One Sprint Planning per sprint: 2 hours minimum
  • One Sprint Refinement per sprint: 1 hour minimum
  • One Sprint Retrospective per sprint: 1 hour minimum

This adds up to at least 8 hours per developer per 3-week sprint. A more effective method to prevent development teams from losing one whole day of development time is shown in the following table.

ScrumEvents Refined scrum events to save time

By spending an hour on the planning and any remaining time on the retrospective, as needed, teams will realize approximately 60% in time saved from this alone. The Sprint Refinement session should not be skipped, as Teams benefit from them substantially. It is still an important meeting for backlog prioritizations and preparing for a smooth planning session. LAlso, the Daily Scrums at 15 minutes are efficient for understanding blockers and progress for the day. Teams have generally seen success with these meetings capped at four days per week, allowing them to spend Fridays on ‘Focus Time,’ providing updates virtually. This ‘Focus Time’ allows teams to spend their time on deep, uninterrupted focus and development-related work for one day per week.

Team Capacity

The process of estimating and assigning story points during Scrum refinements and planning sessions can be ambiguous at times. T-shirt sizes may work well, but do not always clearly map back to story points or hours. Scrum uses the Fibonacci sequence for point assignments because its non-linear progression reflects the increasing uncertainty and complexity of larger tasks, intending to make it easier for teams to estimate effort.

An alternative, possibly more effective approach, could be to create a time-mapped story point estimation guide that includes a clearly defined analogy and corresponding t-shirt size for additional clarity. The following table clearly shows how points in the Fibonacci-like sequence are mapped to hours, along with clearly defined analogies and T-shirt sizes. This provides clarity and prevents confusion during the planning process.

StoryPointDefinition time mapped story point estimation

So, a 3-week (15-day) sprint equates to 50-60 points for optimal velocity based on available capacity, which also accounts for meetings and other unplanned work. Following a system like this ensures that all development teams are aligned with organizational standards and expectations for success.

Ticket Intake Process

Now that we have established the modified Scrum roles and events, let’s look at how we can structure an intake process for customers to submit their requests via tickets that can be directed to the various teams. A simple form structure, like the illustration below, works best to help channel the requests to the appropriate team. A Data & Analytics team may be responsible for Reporting, Data Engineering, Enterprise Data Warehousing, and Advanced Analytics requests. By having detailed forms and sub-forms within them, customers’ requests can be channeled to the applicable team more successfully.

IntakeForm Sample dna intake form

Having the requests flow to a centralized Service Board allows a Team Lead to review, refine, and funnel the tickets to the right team’s project boards. An efficient method of setting up the intake form to enable automated workflows for routing tickets appropriately could be to add the dropdown selections to the various forms, as seen in the image below. If the team is split into departmental divisions, a customer could select the Analytics Division, based on Business Function. Then, they could be prompted to select a sub-division or focus area to further refine which team member to assign the ticket.

DivisionDropDown dropdowns added to forms to capture which team and assignee to route the request to.

Ticket Servicing Flow

We now have the best structure of the Scrum team and Customer intake boards in place. Let’s look at how these tickets flow from the customer to the service board intake queue to the individual team project boards while leveraging automation workflows to help orchestrate and streamline the process:

TicketServiceFlowDetail Detailed flow of the ticket to completion

The steps include:

  1. Customer Creates Ticket: First, the customer will create and submit a request form, which creates a ticket in the Data and Analytics service board. If the ticket needs more details, the administrator will respond to the customer before approving the ticket.
  2. Automation Workflow Creates Project Card: Automation workflows will be in place to enable Approvers to approve or respond to the customer before approval. The automation workflow will then determine which project board and assignee to assign the ticket. It will create a new Scrum project card in the correct Project team’s board backlog and set it to ‘To-Do.’ It will also add Requestor details and any relevant links to the new project card’s description. It will also link the original service ticket to the new project ticket as a child item. Lastly, it will set the original service ticket to ‘Approved.’ This separation of the service ticket and project card allows the project card to move through the Scrum process and capture notes internally without impacting the original ticket. The Assignee can still communicate with the customer in the original ticket, and the original ticket remains open until the Project card is ‘Done.’
  3. Project Card is Completed: When the Assignee completes the work, marking it as ‘Done,’ the automation workflow will also mark the original customer ticket as ‘Completed.’ This will close the ticket and a notification will be sent to the requestor indicating that the ticket has been completed and closed.

Conclusion

This tip has provided some in-depth ways of effectively managing Agile Scrum teams using modified Scrum-based techniques aimed at:

  • Shortening meeting times and allowing developers to spend more time doing what they love to do: deep-focus work and heads-down coding.
  • Saving organizational cost from not having to staff redundant roles and expanding the responsibilities of the Team Manager.
  • Managing team capacity effectively by defining a structured benchmark for story point estimation.
  • Streamlining the customer ticket servicing workflow using scalable automation approaches. Such as support for easy routing, tracking, and overall management of customer requests through the development lifecycle, preventing bottlenecks in the process.

Next Steps

Related Posts

Leave a Reply

Your email address will not be published. Required fields are marked *