As described in the Scrum Guide, the Product Backlog is an ordered list of everything that is known to be needed in the product. It is the single source of requirements for any changes to be made to the product.
But when is the product backlog created? Is it before the start of the first Sprint in a separate workshop session? Yes it gets refined during Sprints but at the start, in what event are the user stories for the product backlog captured?
Sprint Planning (which is the first event in the sprint cycle) is selecting items from Product Backlog into Sprint Backlog + a plan to deliver them into an increment. Does that mean we usually have a separate event before the first sprint to create the product backlog?
You have just identified one of the gaps in Scrum when you try to use it on projects rather than well established products.
Creation of the initial backlog needs to happen before the first sprint so some folks have invented the concept of Sprint 0 to handle this along with many other mobilization activities.
I prefer to use the DAD phase "Inception" as it is more honest to say that in many companies, you cannot get through mobilization within 1-4 weeks...
Kiron
...
1 reply by Mohit Joshi
Jul 29, 2020 11:24 AM
Mohit Joshi
...
Thanks Kiron.
Have been reading a little on DAD and found this good article in PMI resource library. Sounds like the "Inception" phase addresses the need of a "Sprint 0".
Drew CraigSr. Agile & Product Coach| VanguardPhiladelphia, Pa, United States
Often the initial sprint will focus on bringing these pieces together; termed a Sprint 0, Inception, .....
For example, for my current client, we'll have a Sprint 0 that is inclusive of any trainings, sharing vision, journey mapping, experience plan, story mapping, hydrating the backlog. Then Sprint 1 will feed from that backlog. Essentially, it is a preparation period b/t kickoff and Sprint 1 that fills the gap of team selection and execution.
Now, that all said, the intent of the backlog hydration exercise is not to create the entire backlog of work. It is to take some prioritized big-ticket items and work through just enough to get started, deliver something tangible, and elicit feedback. From those learnings, the team will continue to add to the backlog and prioritize as needed.
Some will disagree with the concept of a Sprint 0. My perspective is that although we are not creating a product increment, we are aligning on vision, creating a journey and story map, and building the backlog of work; aka value. This is shared out through regular Scrum events providing transparency and ability to inspect & adapt these deliverables. This also provides a smooth transition for those not familiar with the process and to get exposure. Saving Changes...
The creation of the backlog can begin at the first sprint planning meeting (whether you call that Sprint 0 or Sprint 1). At that stage you only need enough stories to get the team going. The first planning meeting might only be a short one.
Outside of Sprint Planning the Product Owner may add things to the product backlog at any time. Some teams also operate an "open backlog" policy where *anyone* can add stories for future consideration (that doesn't necessarily mean every suggestion added will get chosen by the PO). Another way to populate a backlog is to have Backlog Refinement meetings on an occasional, as-needed basis to create new stories and fill out details of existing ones.
...
1 reply by Mohit Joshi
Jul 27, 2020 2:01 PM
Mohit Joshi
...
Thank you David. But are the stakeholders part of Sprint Planning meeting? I guess not. So, how is the requirement gathering (where user stories are captured) conducted in Sprint Planning? At the beginning, there has to be a workshop session where the stakeholder put forward their wish-list (requirements) in the form of user stories, that would be prioritized & put into the product backlog.
Like Kiron & Andrew mentioned, I also heard about Sprint 0 but it doesn't seem to be in alignment with the Scrum framework. Looks like a gap that different organizations are filling by using Sprint 0.
But apart of Sprint 0 practice, what are the other ways to capture user stories (asking when, not how)? Which event in Scrum is used for it?
The creation of the backlog can begin at the first sprint planning meeting (whether you call that Sprint 0 or Sprint 1). At that stage you only need enough stories to get the team going. The first planning meeting might only be a short one.
Outside of Sprint Planning the Product Owner may add things to the product backlog at any time. Some teams also operate an "open backlog" policy where *anyone* can add stories for future consideration (that doesn't necessarily mean every suggestion added will get chosen by the PO). Another way to populate a backlog is to have Backlog Refinement meetings on an occasional, as-needed basis to create new stories and fill out details of existing ones.
Thank you David. But are the stakeholders part of Sprint Planning meeting? I guess not. So, how is the requirement gathering (where user stories are captured) conducted in Sprint Planning? At the beginning, there has to be a workshop session where the stakeholder put forward their wish-list (requirements) in the form of user stories, that would be prioritized & put into the product backlog.
Like Kiron & Andrew mentioned, I also heard about Sprint 0 but it doesn't seem to be in alignment with the Scrum framework. Looks like a gap that different organizations are filling by using Sprint 0.
But apart of Sprint 0 practice, what are the other ways to capture user stories (asking when, not how)? Which event in Scrum is used for it?
The PO is the lead stakeholder. The PO certainly might invite others to a sprint planning session but the first sprint tends to be somewhat occupied with discovery and ramp-up activities and the PO probably starts off with his or her own idea of what to do first.
The first sprint ought to include some Backlog Refinement events and the Scrum guide says that the team should decide when to do that. Any time is a good time to add things to the product backlog! Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
Important thing to understand is product backlog are not requirements. People have to create requirements from product backlog. When it is created? Before the decision to start the initiative to create the solution.
...
1 reply by Mohit Joshi
Jul 27, 2020 6:06 PM
Mohit Joshi
...
Thanks Sergio. I need to understand your response more.
When you say Product Backlog is not requirements, what do you mean? As described in the Scrum Guide, the Product Backlog is an ordered list of everything that is known to be needed in the product. It is the single source of requirements for any changes to be made to the product.
Yes, it may mean what you have in the Product Backlog may not be actual requirements but wish-list from stakeholders that needs to be refined, decomposed (into tasks & put into Sprint Backlog) and prioritized, shouldn't it be containing to the minimum those items that can get the scrum team started with Sprint 1 to produce a releasable increment of the desired product?
In my view, there must be some form of a workshop session or a pre-Sprint event where those items are identified & added to the initial backlog. While some label it as Sprint 0, others state it should be part of Sprint Planning for Sprint 1. Not sure in real world, which is recommended.
Important thing to understand is product backlog are not requirements. People have to create requirements from product backlog. When it is created? Before the decision to start the initiative to create the solution.
Thanks Sergio. I need to understand your response more.
When you say Product Backlog is not requirements, what do you mean? As described in the Scrum Guide, the Product Backlog is an ordered list of everything that is known to be needed in the product. It is the single source of requirements for any changes to be made to the product.
Yes, it may mean what you have in the Product Backlog may not be actual requirements but wish-list from stakeholders that needs to be refined, decomposed (into tasks & put into Sprint Backlog) and prioritized, shouldn't it be containing to the minimum those items that can get the scrum team started with Sprint 1 to produce a releasable increment of the desired product?
In my view, there must be some form of a workshop session or a pre-Sprint event where those items are identified & added to the initial backlog. While some label it as Sprint 0, others state it should be part of Sprint Planning for Sprint 1. Not sure in real world, which is recommended.
...
2 replies by David Portas and Sergio Luis Conte
Jul 27, 2020 6:12 PM
David Portas
...
Mohit,
An item on the product backlog is a promise of a conversation, not a contract. I expect that is what Sergio means when he says the backlog items are not requirements.
Sprint 0, Sprint 1 is not important. Populate the backlog whenever it is convenient to do so.
Jul 28, 2020 8:43 AM
Sergio Luis Conte
...
You use the exact words: needs, wishes, and I can add desires, wants, etc. All these stuff has to be translated into something you can use to create the product. So, requirements is somethings that will allow you to create something, mainly because it has to be well stated and to achieve that you can use the method/technique that best fit for your current state. Just to take an example, if you use user stories take a look to the user story definition: "an invitation, a placeholder for a conversation". So, you have to take all that before a project is in place, including it inside the backlog you will have things that will define the approach you will use, the method/framework you will use, the project life cycle you will use and things like that.
Thanks Sergio. I need to understand your response more.
When you say Product Backlog is not requirements, what do you mean? As described in the Scrum Guide, the Product Backlog is an ordered list of everything that is known to be needed in the product. It is the single source of requirements for any changes to be made to the product.
Yes, it may mean what you have in the Product Backlog may not be actual requirements but wish-list from stakeholders that needs to be refined, decomposed (into tasks & put into Sprint Backlog) and prioritized, shouldn't it be containing to the minimum those items that can get the scrum team started with Sprint 1 to produce a releasable increment of the desired product?
In my view, there must be some form of a workshop session or a pre-Sprint event where those items are identified & added to the initial backlog. While some label it as Sprint 0, others state it should be part of Sprint Planning for Sprint 1. Not sure in real world, which is recommended.
Mohit,
An item on the product backlog is a promise of a conversation, not a contract. I expect that is what Sergio means when he says the backlog items are not requirements.
Sprint 0, Sprint 1 is not important. Populate the backlog whenever it is convenient to do so. Saving Changes...
With Scrum, the first thing we do is creating the Product Backlog, that is the list of features we are minded for the project. It's equivalent to scope definition in cascade project mode, but the difference is that Scrum allows Backlog refining through the course of the project. Features are transferred into sprints to be executed, while other features are added or eliminated.
...
1 reply by Mohit Joshi
Jul 27, 2020 8:15 PM
Mohit Joshi
...
Thanks Veronica. Sure, we can say product backlog is kind of scope definition. But more than "what" part of the artifact, I am interested to know "when" the initial product backlog is created (or rather recommended to be created) before the first Sprint begins.....at some point during the start of the product development, the key stakeholders would meet with PO & share the list of features they would want in the product. Then the PO & other Scrum team can meet during Sprint Planning to select the story points for the upcoming Sprint (Sprint Backlog). When does this occur & in what event?
Based on the inputs received so far, either Sprint 0 (practice followed by some) or part of Sprint Planning for Sprint 1 (not sure how it is possible though in real world).
Sure, once created, the PB can be refined anytime (on going process).
With Scrum, the first thing we do is creating the Product Backlog, that is the list of features we are minded for the project. It's equivalent to scope definition in cascade project mode, but the difference is that Scrum allows Backlog refining through the course of the project. Features are transferred into sprints to be executed, while other features are added or eliminated.
Thanks Veronica. Sure, we can say product backlog is kind of scope definition. But more than "what" part of the artifact, I am interested to know "when" the initial product backlog is created (or rather recommended to be created) before the first Sprint begins.....at some point during the start of the product development, the key stakeholders would meet with PO & share the list of features they would want in the product. Then the PO & other Scrum team can meet during Sprint Planning to select the story points for the upcoming Sprint (Sprint Backlog). When does this occur & in what event?
Based on the inputs received so far, either Sprint 0 (practice followed by some) or part of Sprint Planning for Sprint 1 (not sure how it is possible though in real world).
Sure, once created, the PB can be refined anytime (on going process). Saving Changes...
"If they have moving sidewalks in the future, when you get on them, I think you should have to assume sort of a walking shape so as not to frighten the dogs."
