nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

What is the impact of raising a spike to sprint burndown chart?

Ahmad Fikhri Bin Dakhirrudin

Hello,

I am new to JIRA. Me and my squads has been raising user story as "Story" but I noticed that for story that requires investigation or research before delivering the actual story, we can raise it as "spike".

I have never tried this so I would like to ask the community if you know whether it will have any impact on my burndown chart if we are unable to finish the "spike" story in 1 sprint?

Accepted answers

Walter Buggenhout

Hi @Ahmad Fikhri Bin Dakhirrudin and welcome to the Community!

Whether a spike impacts your burndown chart or not is all down to the almighty power you have when organising your team's work.

Your burndown chart burns down something - when you define stories, very often that will be story points. If you estimate your spike in story points (or if you use something else to estimate your stories in - the same estimation statistic as your stories), this will indeed be included in your burndown chart.

In agile practice, spikes are usually time-boxed experiments to validate an idea. They do not deliver actual value to your customer, but help you validate an idea. So if you add the estimate in time to the original estimate field of a spike and estimate your stories in story points, your spike will not impact the burndown chart directly. Of course, the time spent on running the spike is time you cannot spend on developing stories and so - indirectly - you will possible be able to deliver fewer stories in a sprint.

Hope this helps!

All comments

Bill Sheboy

Hi @Ahmad Fikhri Bin Dakhirrudin -- Welcome to the Atlassian Community!

The answer may depend on how your team works...

If you created a Jira issue for the "spike",
And your team sized it using your estimation statistic for the board (e.g., time, story points, count, etc.),
Then the issue's progress will appear on your reporting, such as the burn charts.

What is your concern about showing, or not showing, the issue on reports if the team is doing the work?

Kind regards,
Bill

Walter Buggenhout

Hi @Ahmad Fikhri Bin Dakhirrudin and welcome to the Community!

Whether a spike impacts your burndown chart or not is all down to the almighty power you have when organising your team's work.

Hope this helps!

Ahmad Fikhri Bin Dakhirrudin

Hi @Walter Buggenhout , thank you for your feedback. It is clear now. So basically it is still a story that needs to be completed within 1 sprint. It just that, it does not deliver an actual value to the customer am I right?

Ahmad Fikhri Bin Dakhirrudin

Hi @Bill Sheboy ,

I am just trying to understand what is the difference between a spike and a story. But I understand now based on @Walter Buggenhout explanation.

Walter Buggenhout

Yes, @Ahmad Fikhri Bin Dakhirrudin. But if you want to clearly see the difference between stories (actually building / delivering value for your customer) and spikes (running experiments), I would really recommend you to set up a different issue type for your spikes.

You will be happy afterwards if you can easily report on e.g how many spikes have been completed, maybe have the benefit to define a different workflow for the two and so on.

Bill Sheboy

In my experience, there are different definitions for the concept of a "spike", so how you handle these depends on your team's understanding.

A simple definition is "a task included in an iteration plan that is being undertaken specifically to gain knowledge or answer a question" (from Agile Estimating and Planning by Mike Cohn).

Some even have different types of "spikes" based on the need. For example,

"Research: broad, foundational gaining of knowledge to decide what to spike or to obtain the ability to estimate features desired in the future
Spike: a quick and dirty implementation, designed to be thrown away, to gain knowledge about a larger feature or integrating technology
Tracer bullet: a narrow implementation in production quality of a large feature to be implemented into the product later that will enable the team to better estimate the remaining feature work"

To learn more about these ones, please see Managing Software Debt: Building for Inevitable Change by Chris Sterling.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

cloud

jira-software

jira-software-cloud