Skip to main content

Pointing in-flight work that ended up being unnecessary and adding no value

Last post 05:52 am February 17, 2022 by Jaya Agnihotri
4 replies
08:36 pm February 8, 2022

During our sprint planning, we committed to a ticket written awhile ago that's been sitting in our backlog. The ticket was made by a brand new PO for a complex body of work but it was lower priority so we're just now getting to it. We estimated 5 SP for it.

The ticket was worked on and work was completed but we held off on completing our DoD steps because we found a related bug. We created another ticket for that and began investigating. The PO went ahead and confirmed the team should complete the work while waiting for confirmation from our Product team. The Product team got back to us and confirmed the original ticket as part of our sprint commit was not needed (the functionality was not desired at this time) and therefore the "bug" we identified was not actually a bug.

The problem is: the team completed the work (thankfully didn't merge anything). So there was wasted effort.

The PO deleted the original ticket and the bug ticket and created an interrupt ticket to cover both, assigning the 5 SP to that since the work done was throwaway and didn't deliver any value to the product.

Is there any issue with how we handled the tracking of the story points?

Should we have handled it differently? Not tracked the story points at all? Or....? 

Just curious what the proper protocol would be in this case.

 

Thanks!


10:37 pm February 8, 2022

The proper protocol is to forget about being a story point accountant, and to honor the commitments associated with each Scrum artifact as opposed to committing to tickets.

Bear in mind that velocity is the rate at which work is Done, and not partly Done. Developers may use this measure to estimate how much work they can take on to meet a Sprint Goal by crafting a Done increment.


11:32 pm February 8, 2022

I don't think there is "proper protocol". There's no one-size-fits-all answer or approach to this problem, but I'm sure you can get plenty of really good opinions or perspectives on how this went down.

It seems to me like story points mean something to your organization. I don't understand what an "interrupt ticket" is, what value creating one would add, or why one would be assigned points. Story points are only useful to the team at the point of refinement and planning, as one potential tool for helping the team think about the amount of work they have done in the past versus forecast capacity and amount of work. Once a Sprint has been planned, there's not much value in playing accounting games with points.

If it was determined that work was no longer needed, my recommendation would just be to close the representation of that work as "won't do" or delete the item or throw away the card, depending on the tools and the team's need for record keeping. If any work has been started, that can also be discarded.

For me, the biggest concern would be around why this work was started in the first place. I'd want to understand why it remained in the Product Backlog if it was no longer necessary. It may be a good idea to look at the rest of the Product Backlog and make sure everything else represents work that is valuable and desired by stakeholders, closing out or removing anything that is no longer necessary or relevant. Problems should be fixed at the root cause, and getting to problems in backlog management would get you much closer to the actual root cause.


12:03 am February 9, 2022

I'm going to echo @Ian and @Thomas.  

Points are estimates made based upon information known at the time the estimate is made.  Once work begins, you will undoubtedly discover new information that will on many occasions invalidate the original estimate.  Using estimates to determine whether a team is delivering is a mistake, in my opinion. I prefer to use metrics like throughput or cycle time.  Story Points are useful for a team to estimate if they feel they can complete work during a specified period of time.  

Is there any issue with how we handled the tracking of the story points?

Should we have handled it differently? Not tracked the story points at all? Or....? 

Just curious what the proper protocol would be in this case.

You are asking those questions of the wrong people.  The only ones that can answer them are people within your own organization.  There is no such thing as a "correct way to use and track Story Points" because there is no methodology or process I have ever encountered that require them to be used.  The current Scrum Guide has no mention of User Stories or Story points. It references Product Backlog Items and doesn't have a single use of any variation of the estimate. 

The problem is: the team completed the work (thankfully didn't merge anything). So there was wasted effort.

However, there is mention in the Scrum Guide of managing your Product Backlog and ensuring that it contains all of the work needed for a Product.  That management is an ongoing activity.  Items that provide no value to the Product should not exist in the Product Backlog.  The fact that this item existed and that it was worked on without determining the value it provided is something that your Scrum Team should discuss.  You need to determine why it still existed in the Product Backlog, why no one questioned the value provided by the ticket, and how to prevent anything like this from happening in the future. As Scrum Master one of your responsibility to the Scrum Team is helping them focus on the high value work. One of your responsibility to the Product Owner is to help understand how to effectively manage the Product Backlog.  

I suggest that you stop worrying so much about how to manage and report Story Points. Instead focus on helping the team and organization understand if value is represented by your Product Backlog items and if value is being delivered in each Sprint.


05:52 am February 17, 2022

I agree with Daniel, Ian and Thomas, The same story can be cancelled, there is no need for interrupt ticket.

This case is retrospective candidate for whole scrum team -

1. SM to help PO to identify and maintain prioritized PB with highest priority items in place

2. PO to work with stakeholders to identify most important items needed by business in near future.

3. Scrum team to get involved with PO and identify the ways everyone can work on focusing on most prioritized item, developers work on ways to improve ways to refrains similar kind of bugs in future

 

 


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.