Misusing Spikes vs. Tasks for Research Items

Do you need more visibility into refinement than allocating some of your capacity in a Sprint to refinement?

If you were to put spikes or other types of research tasks into the backlog (either the Product Backlog or the Sprint Backlog), what are you doing is putting refinement into the backlog. For some teams, this can be a good thing, making sure that the work is clear, well-understood, and visible to the team and stakeholders. For other teams, it can be unnecessary overhead to manage these items in the backlog and its associated tools.

For bugs, if research is needed, the team is required to open up a task for that research. I think it should be a Spike, personally, or just part of the nature of a bug (unknowns, estimation). Spikes are only allowed to be used if there is a specific output, such as documentation, user flow, diagram, etc.

If the team want to manage refinement activities in their Sprint Backlog then that's up to them. I'm more concerned about the words required and allowed and who thinks they're in control of the matter.

Thomas and Ian already pointed all out, so I can only echo them:

• What you described looks like the pursuit of tracking refinement activities.
• Even when you have defined concepts like Spike or Discovery, why someone set enforcing rules on the team about how and if use them?

What we could add to that is to consider how this situation impacts Scrum Values, and what could change (if anything) in order to stay more true to them, for example, Openness and Respect might be worth considering.

• "(...) The Scrum Team and its stakeholders are open about the work and the challenges. Scrum Team members respect each other to be capable, independent people, and are respected as such by the people with whom they work. (...)" ~SG2020

@Ian Mitchell - Unfortunately, we have very opinionated and strong-minded Dev Managers who constantly interject in the scrum process during meetings. They are setting these mandates with the teams.

@Thomas - We only have two 1-hour Backlog Refinement meetings each week so there isn't enough time to fit research/discovery tasks into those meetings. Therefore, that effort (and time) need to be tracked for the team so that's why it's being tracked as an actual task that is time-boxed (just like a spike would be). Then we pull that research task into the sprint and it counts against the story point velocity for the team.

Hi, Gia!

Thank you for all the information that you bring.

If you realize, the problem that you are issuing seems to be thought as:  "what can I do to make my team comply with what has been imposed by the managers, but make the process still effective?"... Let me be a little bit disruptive, but isn't the real problem "How can I make the managers realize that what they are trying to impose is no good and has a lot of wastes for the team and the product that we are developing?"

If the problem is thought in this way, the focus of improvement for this case shouldn't be on the team, but on the managers instead.

What can you do to start facilitating a change of mindset in the managers?

Remember that a Scrum Master is not accountable only with the team, but also with the Product Owner and the organization ;)

In teams I have worked with spikes were used.  But they were created directly in the Sprint Backlog and they were created with a time box, such as 4 hours, to limit the time spent on the activity.  We never saw this as part of our velocity because it is a refinement activity and we already expected to spend time on refinement.  It was useful for them as a means of capturing notes to use when creating items in the Product Backlog. 

Each team decided how and when they wanted to use spikes as this is a procedural thing and not something that the Scrum Guide includes.  As @Ian Mitchell states your indication that each team is not allowed to make these decisions is the part that is most troubling to me. Honestly, if I were in your situation, I'd discourage the team from using spikes entirely. 

@Thomas - We only have two 1-hour Backlog Refinement meetings each week so there isn't enough time to fit research/discovery tasks into those meetings. Therefore, that effort (and time) need to be tracked for the team so that's why it's being tracked as an actual task that is time-boxed (just like a spike would be). Then we pull that research task into the sprint and it counts against the story point velocity for the team.

Refinement is not something that can fit into 2 1-hour meetings each week. It's a continuous activity. It may be helpful to have times where the whole team gets together and aligns on the current state of Product Backlog Items to figure out what is ready for upcoming Sprints, what needs more refinement, and what kinds of work needs to be done to get Product Backlog Items to a ready state.

Although some teams have found success with creating tasks for refinement (either for ordering on the Product Backlog or directly in the Sprint Backlog during Sprint Planning), I've had good luck without creating these extra tasks. Instead of creating a task that says "refine PBI X", you can just say that "I am refining PBI X" and update the representation of PBI X as you carry out refinement. You can timebox refinement without specific work items, and in my experience, teams usually do timebox refinement.

I'd echo the others that the problem isn't figuring out how to manage this refinement effort, but to get management out of the business of telling teams how to work. Let the teams figure out if they want to put refinement on the backlog or not and how to go about managing their time. It needs to be a team decision, not a management edict.

The need for spike or PoC is the technical uncertainty of the solution identified by the team. How the refinement activities can fit in time box or counted for velocity ?(Even the 10% refinement time guidance itself removed now) Does it helps to Forecast for the next spike? or this is a try to foster 'Openness' about the work and challenges to the stakeholders ?

Oh I see - so the teams use the time outside of the specific Backlog Refinement meeting to work on the items in the Sprint Backlog only. They do NOT spend time researching items in the backlog because that would take away their time from completing the items in the sprint. They see it as if they are going to spend time researching and doing discovery work, they want it tracked and accounted for in a sprint so that there isn't hidden work. But you're saying that this should be part of Backlog Refinement and should NOT be tracked?

And if the team is continuously Backlog Refining throughout the sprint, how will they have time to get their Sprint Backlog goal complete? The goals are pretty aggressive (in that our products are very very complex and difficult to understand). Almost every item would need to be researched in some way. It seems there isn't enough time to do all of this.

In our BR meetings, we usually only get through 2-3 stories tops because there is so much discussion that needs to occur and so many unknowns due to the complexity of our financial software.

Oh I see - so the teams use the time outside of the specific Backlog Refinement meeting to work on the items in the Sprint Backlog only. They do NOT spend time researching items in the backlog because that would take away their time from completing the items in the sprint.

The team should be spending time outside of any refinement meetings to perform refinement. It's highly unlikely that the team can do sufficient refinement activities in two 1-hour blocks of time each week. Even if they could, it would not be efficient, since you probably don't need the whole team to refine every single Product Backlog Item.

The Scrum Guide doesn't say how the team conducts refinement. My experience tells me that having a meeting between the Product Owner and the Developers at least once a Sprint to synchronize on the current state of the Product Backlog to support refinement tends to be helpful. Ultimately, the team should decide how to do refinement, including what meetings to have, who should be there, how to track what needs to be refined, and so on.

They see it as if they are going to spend time researching and doing discovery work, they want it tracked and accounted for in a sprint so that there isn't hidden work. But you're saying that this should be part of Backlog Refinement and should NOT be tracked?

Does the team want this or does management want this?

If management wants this, that strikes me as a lack of trust in the team to effectively use their time. However, if this is something that the team wants to do, then they should look for ways to make the refinement work more visible. There are plenty of different ways to do this, and the tools that the team use may influence how making refinement visible is accomplished.

My experience tells me that it's not often necessary to track and make refinement explicitly visible. It is implicitly visible as the team makes the Product Backlog better. Anyone with visibility into the Product Backlog should be able to see when Product Backlog Items are split, reordered, or enhanced with additional details. The visibility into the Product Backlog is often, but not always, sufficient.

And if the team is continuously Backlog Refining throughout the sprint, how will they have time to get their Sprint Backlog goal complete? The goals are pretty aggressive (in that our products are very very complex and difficult to understand). Almost every item would need to be researched in some way. It seems there isn't enough time to do all of this.

Time needs to be set aside for refinement at Sprint Planning. The amount of time needs to be considered when the team determines how much work should be brought into the Sprint. If they look at the Product Backlog and see that a lot of the items close to the top are not ready for an upcoming Sprint, they can decide to allocate more time for refinement and have less deliverable work in the Sprint Backlog. Conversely, if the Product Backlog has a lot of ready work in it, then perhaps the team doesn't need the time to refine and can bring in more work.

Sprint Planning isn't an exact science. There are tools to help. Some teams use story point sizing and velocity. I prefer thinking about things in ideal hours and forecasting actual hours. There are ways to gauge the confidence of the team in their ability to achieve the Sprint Goal, like fist-to-five voting. Using different techniques can help the team understand how much work to bring in and how much time to allocate to other stuff, including refinement.

If your goals are so aggressive that you're having trouble finding the time to refine, the problem may be your goal. Working at a sustainable pace is a value of Agile and Lean. If you can't refine upcoming work to be prepared to work on it, what else is being sacrificed in favor of highly aggressive goals?

@Thomas - Thank you for your insight. This is very helpful. Management wants the team to track absolutely everything they do so that's why the team is feeling pressured to create "research" tasks with time-boxes to account for the time/effort it will take to do the research (sometimes this involves third-parties or stakeholders and takes some time). Especially with bugs - in my past experience, bugs are unknowns and therefore, weren't story-pointed. Here though, bugs have to be story-pointed so research has to be done so the team understands what the effort will actually be (to the best of their ability). It's all becoming so process-heavy and I don't know how to get the teams out of this loop they're in. Dev Management is acting like a strict parent/dictatorship with the teams.

Dev Management is acting like a strict parent/dictatorship with the teams.

As you said earlier "They are setting these mandates with the teams". That's the problem, and it's what a Scrum Master ought to wonder about and shine a light on. What does it say about respect -- and a team's ability to inspect and adapt -- when decisions are being made by others who are not accountable for the outcomes?

@Ian Mitchell Yes, that is the overall main problem. Management is not only acting this way, but they are supported by their manager to act this way with the teams. They are held accountable for everything the teams do that they force their ideas on the team to follow.