Skip to main content

Are Sprints and Scrum right for this team?

Last post 05:57 pm January 3, 2023 by Daniel Stillwell
4 replies
09:27 am December 23, 2022

Hi,

This is my first post, it's very nice to meet you.

I have started a new role as a Scrum Master for 3 teams, two of which practice what I would associate as "normal" software development towards Products, but the other team is quite different.

The codebase for the main product is large and features are added regularly, and as such, performance becomes an issue. The team in question for this post is all about maintaining and optimising performance.

Unlike my other teams that operate from a product roadmap, this team investigate areas for performance gains and then act on them. This means that they generally dont know what will come next until investigations give them the answers.

I've come into the team and they have been operating Scrum in 2 week Sprints, and finding predictability on an almost unknown backlog of work is very difficult. I liken it to an adventure book, "to see if performance gains can be found in library X turn to page 143."

The work is logged in Jira and tracked via the scrum board and improvements are sized in story points, but i find myself asking "why obtain a velocity when we dont know how big the work is?"

It's a bit of a head scratcher for me and i would be interested to hear if other people operate in this just in time model.

Thanks


06:11 pm December 23, 2022

they generally dont know what will come next until investigations give them the answers.

If those investigations were carried out, would the work then be ready for Sprint Planning?

In other words, is the size and shape of it then understood well enough for the Developers to feel confident it can be Done in a Sprint?


08:56 pm December 23, 2022

I can see two ways to approach this problem.

One approach would be to identify the performance issue or opportunity for performance improvement, order those, and have the team work on each one in so order. The team would work through the queue of performance issues and improvement opportunities, taking on each one in order until some gain was realized and then moving onto the next.

Another approach would be to identify issues or opportunities, but maintain a backlog of specific, focused changes that the team can deliver within an iteration. Refinement would take an opportunity or problem and decompose it into the discrete units of work that can be ordered and then delivered by the team. You would allocate some time for refinement and some time for delivering the work.

Both are equally valid approaches. The second would be more consistent with Scrum. The first would lend itself better to exploratory and just-in-time approaches.

However, something else to consider would be to not have a team dedicated to these performance issues. Including performance testing and ensuring profiling and performance monitoring is in place would be appropriate for a Definition of Done. Each change to the system can be evaluated against performance requirements and ensure the system keeps a suitable level of quality. You may even be able to have three teams collaborating on delivering features and functionality instead of one team effectively supporting undone work.


09:41 pm December 24, 2022

How do they decide what to investigate?



Maybe the team needs consider the investigation and the solution as one Product Backlog Item?


11:50 am January 3, 2023

How do they decide what to investigate?

Maybe the team needs consider the investigation and the solution as one Product Backlog Item?

The team will have a high level theory of areas they want to investigate, or, they will focus on a method they think that can improve performance.

At present, it is possible that the investigation AND the solution, or rather, the investigation and the changes are being done in a single backlog item, the term we use is "spiky story", as the initial investigation (the spike), often leads to a change that adds the value.

 


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.