Skip to main content

Misusing Spikes vs. Tasks for Research Items

Last post 05:38 pm October 25, 2021 by Gia Madson
16 replies
03:45 pm October 20, 2021

There seem to be two rules of thought at my company around how to track research/discovery tasks. 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.

I think the output of a spike could just be that a decision is made on how to approach a bug or story. The team won't accept a Discovery sub-task either since we can't track that effort properly and account for it in a sprint iteration. 

Any thoughts on how best to handle research tasks for bugs or stories?


04:29 pm October 20, 2021

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.


06:07 pm October 20, 2021

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.


07:35 pm October 20, 2021

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

07:39 pm October 20, 2021

@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.


07:43 pm October 20, 2021

@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.


08:13 pm October 20, 2021

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 ;)


08:24 pm October 20, 2021

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. 


12:00 pm October 21, 2021

@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.


12:52 pm October 21, 2021

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 ?

 

 


02:07 pm October 21, 2021

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?


02:14 pm October 21, 2021

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.


02:27 pm October 21, 2021

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.


02:45 pm October 21, 2021

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?


03:04 pm October 21, 2021

@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.


04:04 pm October 21, 2021

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?


05:38 pm October 25, 2021

@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. 


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.