Does scrum answer the question of when a particular PBI will be done?
Hi everyone,
We have a discussion with a colleague of mine about what scrum does and what it doesn't. He insists that scrum answers the question of when exactly a particular Product Backlog Item will be implemented by a scrum team thru knowing the team's velocity. From my understanding of scrum, there're no such things as "velocity" or knowing when exactly a PBI is going to be implemented. Scrum serves a different purpose. Thus it doesn't answer any questions or this one in particular. Please help us agree or resolve the topic for this discussion.
The Scrum framework doesn't offer or mandate a specific tool or method for forecasting long-term completion of work. Although using velocity is something that some teams do, other techniques, such as those presented by Dan Vacanti in his Actionable Agile Metrics books.
A forecast can be made about when a particular item might be delivered, based on the rate at which work is Done. In Scrum people commit to goals however, not to a forecast of work. A particular item may not be delivered at all. Instead, there are experiments to be run and hypotheses to be tested.
As others have mentioned, the Scrum Guide has no position on velocity.
The Scrum.org glossary provides this definition for velocity…
“Velocity: an optional, but often used, indication of the amount of Product Backlog turned into an Increment of product during a Sprint by a Scrum Team, tracked by the Developers for use within the Scrum Team.”
Velocity is a tally of all story points sizes for work completed over a period of time. An “indication of the amount of Product Backlog turned into increment". This has nothing to do with specific Product Backlog Items. Knowing that your velocity is 123 points does nothing to inform a single item, when it will be done, or, to borrow from Ian, if it will be done at all.
The Daniel S. Vacanti books Thomas mentioned are absolutely worth checking out. Actionable Agile Metrics and When Will it Be Done were game changers for me.
a PBI is done when it meets the Definition of Done !. It need to be sized to complete within a sprint. Scrum does not explicitly say about velocity. Any technique, method to size a PBI can be used by the team within this framework.
He insists that scrum answers the question of when exactly a particular Product Backlog Item will be implemented by a scrum team thru knowing the team's velocity.
Saying exactly when something will be done -I don't think this will ever happen. We can forecast based on the average velocity of the team. If you have a feature/epic and have broken it down to smaller stories which have been estimated, then you can give a forecast of when the feature will be completed.
If you use a tool like Jira, there is a release burndown chart which can give you an approximate date (rather how many sprints you would take to burndown all the tasks) when you can release your features. Of course, the prerequisite is that all stories should be estimated, and you should have completed at least 3 sprints (to know your average velocity).
Great, I like philosophical debates. Above all good points.
Scrum (Agile) strives for the PBI's pulled into the sprint to be finished by the end of the sprint. Scrum attempts to deliver in chunks, appose to Kanban that is more a flow process with work in progress limits to improve the flow.
In theory in Scrum, if the team estimated correctly and progress is as anticipated then one can expect all the PBI's to be delivered by the end of the sprint.
However there are a lot of "ifs" in the previous sentence and that points out the problem with the statement, the word "exactly":
when exactly a particular Product Backlog Item will be implemented
Scrum is not meant to be exact. PBI's are pulled in on estimates, like velocity estimates, but nothing is exact. Scrum also advocate for discovery during the sprint. After more insight is gathered an item can be finished,, broken down further with some parts put back on the product backlog, the entire item can be put back on the product backlog or the item can be found not necessary anymore and closed without being finished, to name a few scenarios . There is a lot of flexibility built into scrum and needed by scrum.
But forgive your colleagues for having so much faith in the Scrum process and estimations based on velocity. The ideal is for teams to deliver on all the items pulled in, by the end of the sprint, but we know that process is not an exact science.
As I can state from your comments, Scrum does not rely on velocity to predict future. It's a framework that helps focus on achieving sprint goal rather than ensure precise dates for future releases. Thank you everyone! I believe this topic can be closed.