Are Sprints and Scrum right for this team?
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
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?
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.
How do they decide what to investigate?
Maybe the team needs consider the investigation and the solution as one Product Backlog Item?
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.