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

Do you add story points to everything?

Emma White_ql5fy1

We seem to be adding story points to every little task on the sprint board.

An automated test has to be added to the board so that it goes through the code review process, these are allocated a nominal 0.5 story points to account for the work that a developer must do to review the code. Is this right?

Accepted answers

Jesse Kona

I would only add Story points at the story level, and then only in the grooming period before the sprint.

Bill Sheboy

Hi @Emma White

Rather than adding story points to every issue/item on the boards, what do you think instead of having a conversation with the team about "what does done mean to us"?

Doing that may help the team create/refine items which are valuable/releasable, and improve the ability to size requests to include all necessary work...and so also improve the ability of the team to forecast delivery.

Kind regards,
Bill

All comments

Jesse Kona

I would only add Story points at the story level, and then only in the grooming period before the sprint.

Bill Sheboy

Hi @Emma White

Rather than adding story points to every issue/item on the boards, what do you think instead of having a conversation with the team about "what does done mean to us"?

Kind regards,
Bill

Emma White_ql5fy1

Thanks @Jesse Kona I agree with you so was hoping to find others who are working in the same way.

Emma White_ql5fy1

Hi @Bill Sheboy

Thanks for this. I have had this very conversation recently as our story points currently do not take testing into account. I was told that if they did there would not be enough in the sprint for the developers. I'm hoping to find some real world experience to provide the evidence why we should be working in this way.

Bill Sheboy

Hi, Emma. As your team is using Scrum you may have that information already: consider the requests as the team has received them and look at all of the work to complete items, and how that is managed and split today. Then compare that to what your velocity and sizing instead indicate is happening. Such conversations may also reveal: skillset silos, imbalance of team capacity by skill, rework (e.g. hidden work), refinement being out of balance for demand/capacity, etc.

Welcome!

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

Quick Links

Find more posts tagged with

jira

cloud

jira-cloud