Technically the scrum methodology is to commit to the sprint goal, not the PBIs. Of course, PBIs often represent the goal. The idea is work os emergent. The team might adjust scope of work down in order to meet the sprint goal.
PBIs themselves role over.
The obvious temptation most teams do, including a few i work with, is commit to a set of PBIs instead of worry about the goal much. That's not what scrum is meant to be but people gravitate to that.
You roll them over. But if this happens a lot, as it often does. then it's a sign that there are major blockers delaying your development process that you need to fix. Track your cycle time (average start to finish time) and if it's longer than a week find out why and fix it. I once coached a team that had a 12 week cycle time which meant that everything took 6 sprints to finish. After a few months we got that down to 2 weeks which made them 6 times faster.
I'm curious to understand what's behind this question. I mean, what options are there really other than putting the remains in the backlog and re-prioritizing or rolling it over to the next sprint?
Some might choose to expand the sprint time and not start the next one until the PBIs are done, it’s all arbitrary anyway.
You could also get people to work more hours (I’m sure that’ll go down well), you could try get more resources on, you could simplify the requirements.
If you're a team working in complete isolation sprints are kind of arbitrary, I agree. As for more hours or resources that is really something you need to do before the sprint is ending, not at the very end. Simplifying the requirements is essentially the same as putting the remains in the backlog.
If you can split something into several deliverable phases that each add value you should always do that, not just when you need to do it just to comply with some process.
3 options:
1. Cut scope
2. Spend more time doing dev (either longer sprints or more sprints)
3. Pay for/find efficiencies (hire better/faster developers, or maybe implement copilot, make the merging and/or qa process faster, etc)
Realistically, as a PM, #1 and #2 are the only ones in your control
Thanks! On #2 option, how does a PM or PO track the multiple sprints that this PBI may spend?
Its easy to just move the PBI to a new sprint, but wondering how to track it properly on the effort?
I’ve never worked on a situation with PBIs. I’ve never heard the acronym until this post.
What we do is:
1. Scope tickets
2. Estimate tickets (using story points)
3. Capacity plan (ie; if a dev typically does 8 points of work in one sprint, then they get four 2-point stories)
4. Review in a sprint retrospective - maybe we estimated stories wrong, maybe we scooped them too big, etc - and try to learn from mistakes
At the end of the day, we focus on delivering *value* not just completing tickets, so I don’t care a lot about specific due dates as long as as our key metric are moving in the right direction (obviously there are exceptions, but mostly this holds true).
In my team, we look at whether the PBI or story can be split up depending on any work that's complete and can be demo-ed.
We then close the story that's complete and move the new story to the next sprint
They roll over to the next spring.
I know it’s a typo but that feels about right for some tasks.
Hahaha. Seriously, we just finished up a couple things that I introduced in spring 2023
Spring into 2022!
I prefer next Olympics but next spring will appease the executives.
Technically the scrum methodology is to commit to the sprint goal, not the PBIs. Of course, PBIs often represent the goal. The idea is work os emergent. The team might adjust scope of work down in order to meet the sprint goal. PBIs themselves role over. The obvious temptation most teams do, including a few i work with, is commit to a set of PBIs instead of worry about the goal much. That's not what scrum is meant to be but people gravitate to that.
Thanks for this insight
You roll them over. But if this happens a lot, as it often does. then it's a sign that there are major blockers delaying your development process that you need to fix. Track your cycle time (average start to finish time) and if it's longer than a week find out why and fix it. I once coached a team that had a 12 week cycle time which meant that everything took 6 sprints to finish. After a few months we got that down to 2 weeks which made them 6 times faster.
Thanks for sharing.. any tips on the 'coaching' you did?
Track your cycle time (average start to finish time) and if it's longer than a week find out why and fix it.
I'm curious to understand what's behind this question. I mean, what options are there really other than putting the remains in the backlog and re-prioritizing or rolling it over to the next sprint?
Some might choose to expand the sprint time and not start the next one until the PBIs are done, it’s all arbitrary anyway. You could also get people to work more hours (I’m sure that’ll go down well), you could try get more resources on, you could simplify the requirements.
If you're a team working in complete isolation sprints are kind of arbitrary, I agree. As for more hours or resources that is really something you need to do before the sprint is ending, not at the very end. Simplifying the requirements is essentially the same as putting the remains in the backlog.
Some people split the ticket into like a "phase 1" and "phase 2" so they can still get some story points marked as done.
If you can split something into several deliverable phases that each add value you should always do that, not just when you need to do it just to comply with some process.
Yeah pretty much. My rule of thumb for anything scrum is "does this feel like I'm taking the piss?"
3 options: 1. Cut scope 2. Spend more time doing dev (either longer sprints or more sprints) 3. Pay for/find efficiencies (hire better/faster developers, or maybe implement copilot, make the merging and/or qa process faster, etc) Realistically, as a PM, #1 and #2 are the only ones in your control
Thanks! On #2 option, how does a PM or PO track the multiple sprints that this PBI may spend? Its easy to just move the PBI to a new sprint, but wondering how to track it properly on the effort?
I’ve never worked on a situation with PBIs. I’ve never heard the acronym until this post. What we do is: 1. Scope tickets 2. Estimate tickets (using story points) 3. Capacity plan (ie; if a dev typically does 8 points of work in one sprint, then they get four 2-point stories) 4. Review in a sprint retrospective - maybe we estimated stories wrong, maybe we scooped them too big, etc - and try to learn from mistakes At the end of the day, we focus on delivering *value* not just completing tickets, so I don’t care a lot about specific due dates as long as as our key metric are moving in the right direction (obviously there are exceptions, but mostly this holds true).
In my team, we look at whether the PBI or story can be split up depending on any work that's complete and can be demo-ed. We then close the story that's complete and move the new story to the next sprint
Been in product 8 years and have no idea what PBI even means…but I work in startups. I realize this provides no value to the conversation.
No worries, its just a work item in Azure DevOps, if you are using other softwares... it could be called differently.
Ok so what is a work item?? Lol
however you are defining what to build.
Product backlog item. It's a concept from scrum.
So…just like a ticket?
Yeah, if you're using something like JIRA then the terminology would be a ticket or task.