New to Scrum and as a PSPO. What is really done in the first Sprint Planning and when does Product Backlog refinement happen?
Hi,
I have recently obtained my PSPO I certification and, since then, I have been studying more about the practical aspects of a Product Owner's job. Because of that, I have been raising some questions.
One of them regards to the very first Sprint. I understand that according to the Scrum Guide, the Sprint Planning is supposed to serve to come up with a plan for the Sprint. The PO should present his/her value proposition for the Sprint, the whole Scrum Team should decide on a Sprint Goal that translates that proposition. Then, Product Backlog items must be selected to be included the Sprint Backlog and the Developers must estimate them (refinement might happen here).
Let's say that we use user stories to sustain the Product Backlog. I have read in many places online that Product Backlog refinement should happen before the Sprint Planning and that this should be done by the PO - as a preparation work - after he/she met with the key stakeholders, users and his/her Developers. There are also references to the existence of a "Backlog refinement meeting", where the Product Owner presents user stories, which are then going to be discussed and decomposed by him/herself and alongside the team.
While I might see this happening after the first Sprint has begun, let's say, at the end of the first Sprint and before the second Sprint Planning, I am struggling to understand where this could take place for the first Sprint... If there is no Sprint Zero, would it be acceptable for these discussions to be taking place with the Scrum Team before the actual start of the Sprint (with the Sprint Planning)?
What do you think from your experience?
In Scrum, the imperative is to establish and maintain empirical process control. There is no excuse for putting this in delay, which means we want to start Sprinting now.
Once a team recognizes that the first timebox must surely have already started -- because neither innovation nor the market will wait -- any barriers to Sprint Planning must be immediately removed. For example, a team might create a bounded environment for taking necessary action, such as a brief workshop, within which a Definition of Done can be agreed along with just enough of a Product Backlog to allow planning to commence.
Apart from the Sprint itself, the Sprint Planning Event has the largest time box. Up to a maximum of 8 hours. A lot can be achieved in an 8 hour period for that first Sprint Planning including establishing your initial Definition of Done, ensuring there is a Product Goal, determining the first Sprint Goal and building a Product Backlog that contains just enough backlog items needed for the Sprint Goal. You can refine backlog items during this time, or factor it into the Sprint as part of the plan. While it would be good to start with some refined backlog items, it doesn't have to be a barrier. Start by starting.
@Miguel congratulations on passing the PSPO certification.
Sprint Planning starts the Sprint and it is considered as the first event in Sprint, comprises of Sprint Backlog and Sprint Goal. It is a collaborative work of the entire Scrum Team and addresses the “Why, What & How” items are selected to achieve a Sprint Goal, time boxed to a maximum of eight hours for a one-month Sprint.
In your first Sprint Planning you have to work backwards from your last day of Sprint or work from your first day of Sprint to determine your schedule of refinement/grooming etc.
You need to understand your Sprint Cycle, for example in my Organization, Sprints starts on a Wednesday for two weeks and there are 7 teams, each have different days they do their Refinement and Retro.
In the 10 days of iteration, in my own team, we have the following:
Daily: Daily Scrum
Day 1 Retrospective
Day 1 Planning which includes prioritization, capacity analysis, selecting tickets for the Sprint and estimating tickets (if applicable).
Day 1 Start Sprint
Day 6 Backlog Grooming/Refinement.
This includes adding details to existing items, estimating, deleting items, adjusting priorities, splitting PBI so as to better fit within a Sprint and adding new items (This is also in preparation for next Sprint)
Day 10 Review/Showcase
Some teams do the Refinement, Prioritization and Estimating separately, it depends on what your team feels comfortable with however, the grooming should precede the planning, and it can be done either on day 4/5/6.
Please note that during the Sprint, there could be a need to add tickets which will necessitate the PBL refinement/grooming given that if you add tickets, you must remove tickets from the Sprint Backlog unless the Developers do not have enough tickets to work on in the Sprint.
Refinement is something that occurs on a continual basis. From the Scrum Guide's section that describes the Product Backlog
Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a description, order, and size. Attributes often vary with the domain of work.
There is no "formal" mechanism for that activity. I coach that refinement can be done by getting a group of people together or by asynchronously via comments in a ticketing system. The key to refinement is communication. You stated "refinement should happen before the Sprint Planning and that this should be done by the PO ". I agree that some refinement should occur before Sprint Planning so that the Developers will have a better understanding of the work that is needed and have some items ready that they feel could be completed in a single sprint. But I disagree that the PO is responsible for that. The Developers are doing the work so they should be involved in the refinement and in some cases do the majority of it so that they can be sure that the work can be accomplished in a single Sprint.
For the first Sprint, I have traditionally coached teams that it will be a learning experience. For that matter, all Sprints should be that way. The team will learn how to work together, how to convey information effectively, how much refinement is enough, et cetera. As the team matures, they continue to learn and improve.
Do not let the fear of "doing it wrong" stop you from starting. Just as you will inspect and adapt your code base, you will do the same for EVERYTHING that the team does. Use empiricism to drive you. According to empiricism all knowledge is learned. And in order to learn you have to do something, inspect the outcome, adapt is necessary.
Another thing to remember is that no team will be at it's best when they start working together. You will make missteps as you go. They are only mistakes if you don't learn from them.