To backlog item or not backlog item
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
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.
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.
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
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.