Skip to main content

To backlog item or not backlog item

Last post 03:07 pm April 26, 2023 by Daniel Wilhite
4 replies
09:45 pm April 24, 2023

Hi

my question is, when is the right time to add a phi to the backlog. Now I know all the stuff around big items, refined items etc etc but question related to lead time.

we use azure devops and lead time is calculated as the time it takes to get from new to done (no surprise there).

we can put everything there as it is thought of but that could distort lead time or we could do a little bit of work and put on backolg when we know it is going to be a thing. I know this could also be misleading but I can see merits both ways.

 

welcome any thoughts

 

 


06:28 pm April 25, 2023

Depending on your process, lead time may not make sense. Many of the teams that I work with use the Product Backlog much like you describe - ideas go into the Product Backlog and they get refined, split, merged. Sometimes, things that go into the backlog become obsolete before they can be worked on. This makes lead time a metric that isn't valuable. It's also why lead time probably isn't one of the four basic flow metrics commonly used in Kanban or Scrum with Kanban - the four flow metrics that are used are work-in-progress, cycle time, work item age, and throughput. Cycle time focuses on the time from when work is actually started to work being complete.


07:41 pm April 25, 2023

or we could do a little bit of work and put on backolg when we know it is going to be a thing

Assuming the Developers' Sprint Goal is flow-based, what will matter is having a clear commitment point in the workflow. Until the commitment point is reached the work may not be done at all. From what you describe, consensus and transparency over where that point lies is perhaps not as it should be.


08:28 pm April 25, 2023

Nice discussion, but could you clarify WHICH backlog are you talking about? It was presumed Sprint backlog, I am sure, but may be, just may be you are talking about product backlog


03:07 pm April 26, 2023

Lead time is a good metric if you are working on things like production outages, infrastructure upgrades and other DevOps type work.  But for software development, the only place I see that it is valuable is if you are working on nothing but defects found in production. 

I agree with @Thomas and @Ian.  The transparency of having "good ideas" that could improve the product in the Product Backlog and then showing that they never became needed is not a bad thing to have.  It can help some people understand that you are not trying to hide information, which in turns gives them more faith in the team and their processes. However, it can lead to a lot of "junk" at the bottom of the Product Backlog unless there is care taken to manage those items as well. 

To @Nicholas' point, I don't usually advocate for something like this to be added directly to the Sprint Backlog unless there is a danger of having to cancel the Sprint if the item is not worked on during the Sprint. Then, in the interest of saving the Sprint, I coach the team to be vigilant and practical.  They should only do as much is needed to complete the current Sprint and everything else should go to the Product Backlog to be ordered appropriately. 


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.