Product Backlog Questions
I have a question regarding, product backlog. Kindly help me.
I am creating a PB for an upcoming sprint planning session. I am confident I can prioritize and use MoSCOW and other techniques. Before getting to this meeting:
-
Do I write would high level user stories and go meeting? I simply don't want to go with PB and then write stuff in the meeting. I want to be as prepared as possible. Any tips you can give me?
-
I have a column for story points, do I leave it blank, then let the scrum team/dev teams decide IN the sprint planning session to agree on the story points? Or do I estimate story points per story and then go to the meeting?
-
I have heard that sometimes user stories are split to be more effective. Do I split user stories once I hear from the development team during the sprint planning session? Is it ok to do that?
-
What is the role of scrum master here?
-
Sprint planning is 2 hours. I plan to spent 45 mins to discuss sprint goal and product backlog. Then use rest of the time to discuss sprint backlog. I have arrived at these numbers (to split time) per the complexity of the project. How do you guys go ahead this?
General question: our sprints are from monday to monday in 2 week fashion. Since my team is in India. Do I start the sprint planning session on friday so that they have tasks lined up for monday? I have heard one or two members not wanting to attending the sprint planning meeting. They tell me they are busy and it is understandable to be honest. Is it mandatory for EVERYONE in the development team to attend? Or should I ask the scrum master intervene?
Do I write would high level user stories and go meeting? I simply don't want to go with PB and then write stuff in the meeting. I want to be as prepared as possible. Any tips you can give me?
Sounds like you're still trying to refine instead of planning what needs to be done. Consider if you should be pulling Refined, Ready items from the Product Backlog as opposed to doing that during Sprint Planning.
I have a column for story points, do I leave it blank, then let the scrum team/dev teams decide IN the sprint planning session to agree on the story points? Or do I estimate story points per story and then go to the meeting?
Per the scrum guide, who should be estimating the work that has to be done? Again, should these be done during Sprint Planning or during refinement?
I have heard that sometimes user stories are split to be more effective. Do I split user stories once I hear from the development team during the sprint planning session? Is it ok to do that?
Once again, Consider if you want to be making these decisions during refinement instead of Sprint Planning.
What is the role of scrum master here?
To teach and coach the team about the various Sprint Events, maintaining Transparency and the overall Scrum framework.
Is it mandatory for EVERYONE in the development team to attend?
IF everyone is not there, would it reduce the transparency? Would everyone understand the goals of the Sprint?
Maybe spin this another way. Start with a Sprint Goal. I like Direction, Demo, Capacity but use whatever helps you.
In that model, you create a Goal to set the direction of the Sprint. Then select all of the PBI's that would need to be completed in order to appropriately Demo that Sprint Goal. Finally, use team Capacity to determine if the Sprint Goal is achievable. If it isn't, remove the lowest priority items until Capacity fits, and refactor the Sprint Goal to match with the collective PBI's.
Are those stories available? Are they estimated by the team or can they be estimated during Sprint Planning? If you presented the team with the Sprint Goal, are there stories missing from the Backlog in order to call it "Done"? Remember that the creation of the Sprint Goal is owned collaboratively with PO and Dev team, so being prepared with one coming into Sprint Planning doesn't mean that will be the Sprint Goal committed to by the Dev team when the Sprint Backlog is ready to start.
@Steve Vb and @John Varela II
Yes I thought more about this. I think I realise that I need to do PB refinement or grooming ahead of sprint planning.
So the Scrum master facilitate the grooming session whereas I as a PO will clarify doubts and help prioritize. My question is:
Do you think a good PO/PM comes to grooming session with the following:
1. Prioritized PBI (PM/PO should have the ablity to answer questions why something is given higher weightage over other item if asked)
2. Written Epics for PBI - atleast on high level
3. Written down user stories - during the meeting you can decide on splitting the stories and estimating stories or removing the once that aren't relevant.
When is the acceptance criteria written? Should this be written during the meeting or can the PM/PO come with the rough draft of sorts?
If the PO suddenly comes up with a requirement that its very urgent and needs to be done and everything about what and how is clear ,Can SM and team try to replace that with a story in the sprint and get that done.
To me this is a Yes they can as we work for the business and the sprint without that functionality is not worth much and the urgency is high.
Your thought around this please
When is the acceptance criteria written? Should this be written during the meeting or can the PM/PO come with the rough draft of sorts?
Are acceptance criteria important if work is to be refined to a “ready” state? If not, why not?
The purpose of Refinement is to add Detail, Order and Estimates to your PBIs. Although you can write the story together, this can be very time consuming for the entire team and in the real world this isn't usually feasible. In my experience, the PO usually brings a "draft" version of the story to Refinement and works with the team to fill in any missing details that are exposed through conversation. As far as breaking the stories down further, that can be decided during Refinement based on many things including can they complete the PBI in one sprint (which would become apparent after estimating) or something as simple as does it make sense. As the previous poster states, the goal is to have the PBIs ready for Sprint Planning.