Sprint Planning + FREE Cheat Sheet
HTML-код
- Опубликовано: 17 апр 2019
- We're looking at Scrum in detail. Today it's the turn of the SPRINT PLANNING.
= = = = = = = = = = = =
New for 2024: my best-ever training:
"How Your Agile Teams Can Achieve Predictability and Productivity WITHOUT Burnout"
→ www.developmentthatpays.com/w...
= = = = = = = = = = = =
Grab your FREE Scrum Cheat Sheet: www.developmentthatpays.com/c...
-------------------
135. Sprint Planning + FREE Cheat Sheet
#SprintPlanning #AgileScrum #DevelopmentThatPays
We are dissecting Scrum to take a look at it piece by piece. Today it’s the turn of Sprint Planning. Sprint Planning is one Scrum’s FIVE EVENTS (what we used to refer to as CEREMONIES) The others being Daily Scrum Sprint Review Sprint Retrospective And the one that wraps them up and ties them in a bow: The Sprint The start of Sprint Planning marks the beginning of the sprint. And the purpose of Sprint Planning … well.. let’s get that straight from the Scrum Guide: “The work to be performed in the Sprint is planned at the Sprint Planning.” Fair enough. And who’s involved “This plan is created by the collaborative work of the entire Scrum Team.” We’ll look at that collaboration in a moment. … after we’ve talked about the inputs and outputs to Sprint Planning. The most obvious inputs and outputs are: Input: The Product Backlog. Outputs Sprint backlog Sprint goal Less obvious…. but the Scrum Guide is here to help: The input to this meeting is the Product Backlog, the latest product Increment, projected capacity of the Development Team during the Sprint, and past performance of the Development Team. This mention of capacity reminds us that, in Scrum, the Product Backlog comes with certain assumptions: That the list of task is prioritised: - Highest Priority towards the top And that the teaks - at least the highest priority tasks - have been Estimated - The Scrum Master calls the meeting. The Development Team - and here the S-Guide is clear - ONLY the Development team… select high-priority items from the (top of) the backlog. They may or may not select the absolute highest. Part of the “art” of Scrum is to select coherent items.- items that make sense to develop together. Sounds like it might be a boring meeting for the Product Owner, Not a bit of it: “The Product Owner can help to clarify the selected Product Backlog items and make trade-offs.”
• Sprint Planning + FREE... 
Хобби
Once more Thank You for clear and understandable explanation! You made me re-read the Scrum Guide and you are correct, the second topic within Sprint Planning has been consistently overlooked at my organization it seems it is always assumed everyone knows the "how" to get the to DONE state for the sprint, consequently we have failed many times.
We're back with another slice of Scrum. This time it's the turn of*Sprint Planning*.
Remember to grab a copy of the Scrum Cheat Sheet. 👍
As always great vid! Can you please do a video where you actually demo a sprint planning session.
I am most interested in how you would conduct the second part of sprint planning - the how - creating a plan.
Thanks
Thank you 😉
You're most welcome!
In my opinion this is where refinement and sprintplanning kind of overlap each other. I've always split refinement in two parts. One would be deep diving in what the stakeholders needs are (where is the business value) and two refining on a technical level to determine how to fulfill the business need. Part two of this approach sounds like topic two in the sprint planning.
The advantage of doing this 'technical refinement' as part of sprint planning however is that the focus is on items that will make it to a sprint automatically and thus prevent any possible waste of time on refining other items.
As long as you refine (on technical level) for items that the product owner puts near the top of the product backlog it doesn't really matter if you call this refinement or planning though. Those items are likely to be put on a sprint anyway so it's just a matter of when you spend time on them, not if.
Many Thanks again Gary - for this crisp and informative video. It was an eye opener for me as well. I also used to think that Sprint Planning is all about the first part. Good to finally get the right picture now. Thanks again :)
What do you mean by "the first part"?
Think Manpreet was referring to the selection of items. (cf. the second part: "the plan for their delivery".)
@@Developmentthatpays that makes sense. I think I got used to discussing and understand what needs to happen to get the items selected done as part of the planning process I didn't think of them as separate parts.
For me the first part of the selection is done by the product owner and tech lead to help prioritize certain items.
Please make videos on PMP exam preparations
No, it's definitely just a process of selection. I'm part of a small team, Sprint planning is usually done by myself (PM) and the dev team (2). It usually takes 30 mins (sometimes a bit more, sometimes a bit less) and we indeed go through the product backlog, latest increment and projected capacity, but in my case the item have been prioritised yet not estimated. That's something we do during the Sprint Planning. Also, I select/assign priority to tasks, not the dev team.
So you cannot say that you are really practicing Scrum and your teams are self-organizing. I see here few major contradictions to the Scrum framework.
To clarify: you assign priority to tasks. Do you also choose that items that will be worked on during the sprint?
@@Developmentthatpays Yes but it's more of a team effort as I obviously need to take into account devs' availability and their constraints.
Very usefull
Glad you liked it!
I keep referring back to this when somebody asks, what do I mean by planning. Thanks very much this and other videos have been very useful.
Delighted that I was able to help!
Clear and useful as all of your videos! Thank you!
In my experience spring planning has been done so wrong, that I won't even start describing it :/
But here I have a question about the Sprint goal. You say that during sprint planning the team select the PBIs and set a Sprint goal. But how can the PBIs be selected without a Goal being set beforehand? I would say that the goal should set the scene for the planning. And since the goal would be the result of previous iterations and user research to determine what next step would add more value to the product, I think that should be pretty much a PO responsibility. Simplifying, the PO would say: ok team, for this and this reason during next sprint we need to focus on introducing feature X. Therefore all these tickets are on top of the backlog. Based on this, go on and select the tickets for the spring backlog. Am I wrong here and have I got the sprint goal wrong? Thank you!!
Don't think you have it wrong; think it's just a case of chicken and egg. Does the goal "arise" from the items at the top of the product backlog? Or does the goal determine the items that are promoted to the top of the backlog?
Where things get interesting - and where the Scrum Guide is super-clear - is when it comes to responsibilities:
- The Dev Team - and the Dev Team alone - selects items for the Sprint
- The PO - and the PO alone - "owns" the product backlog
Given that, can you really say that the PO can "impose" the Sprint Goal? (Bearing in mind that the Dev Team is at liberty to select, say, items #6, #7, #8 and #9 from the backlog.)
@@Developmentthatpays Thank you for your reply! As I have very little experience as PO, videos like yours and this kind of exchange is very useful for me to learn.
I understand what you mean - technically, the goal emerges from the items that are at the top of the backlog and get selected for the spring backlog. Logically, however, I would still argue that, exactly because of that, it is the PO who decides upon it, as they prioritise those items based on user research, business needs, stakeholder requests etc... I mean, what would be her role otherwise, no? The team is at liberty of selecting any items from the backlog, yes, but there has to be a rationale behind it as well - and that rationale should be the sprint goal, right? Thank you again!
Good video, nevertheless as a Scrum Master, I've expected to bu surprised and I wasn't. For anyone who really practicies Scrum it's kinda obvious - at least should be!
Good stuff. To clarify: you create the plan in a distinct and separate step? After you have selected all of the items for the sprint?
What should be clarified for the delivery plan?The details about the technical issues?In general, we always find detail definition issues, technical issues during coding. We cannot ensure all the issues have been explored before implementation.
I agree with you that any attempt to "predict" tech issues would be futile. I know some teams take tickets - *stories* - and break then down into a set of *tasks*. I can the logic of this approach.
@@Developmentthatpays Also using 'Swim lanes' to categorise those tasks based on the original stories, that could make the plan of 'how' for each story more clearly.
Getting Scrum "wrong"? Agile is a framework, not a strict step-by-step process. Some steps don't work well with some groups; whereas others have incorporated as much as a book can teach. The great part about Agile -- and of course, Scrum -- is the ability to find what works best for your team. Too much planning doesn't equal the "best" product.
Although I agree with you in principle, the Scrum religiouso will say if you don't follow everything in the book, you're not doing Scrum. Part of the "working conditions" in our job description is
We use task boards, retrospectives, burn down charts, daily meetings, and product backlogs. However, we’ve adapted parts of various processes (including those of Scrum, Kanban, XP) to satisfy our needs but do not follow any of them to the letter and apply only the ones that make sense for our team.
Scrum is a framework, Agile is a manifesto - set of methodologies / frameworks / approaches / techniques.
Scrum act's as a container. It's boundaries are fixed and needs to be followed, but from the other hand allows you to fill the middle of that container with other sets of practicies / process or whatever you find suitable. However, if you are violating these essential pricinples acting as the boundaries of the container, you are actually using ScrumBut.
Scrum itself is hard to practice, so most likely you might be doing wrong, that's why you find it doesn't work for you. From the other hand Scrum also does not act as a prescriptive method and a panaceum for all project / product development issues you might have.
P.S. I am a professional Scrum Master, who also likes to incorporate Kanban and Extreme Programming practices - usually as complementary towards Scrum framework.