Effective Sprint Planning
HTML-код
- Опубликовано: 8 сен 2024
- In this Scrum Tapas video, Professional Scrum Trainer Don McGreal reviews how he runs a Sprint Planning session with his Scrum Teams. Don focuses on how the Development Team works with the Product Owner to understand what is in the Product Backlog and how they populate the Sprint Backlog.
Great video Don ... especially the tips on facilitating and NOT facilitating ... i.e. let the developers move the stickers from the product backlog into the Sprint Backlog ... supporting the true "ownership of the Sprint Backlog"!
Thank you Don, this was done brilliantly. Appreciate your insight and knowledge.
I really love this break down thank you Sir. I just think you are a good teacher.coz not everyone who knows this can really simplify it like this
Thank you for the improved audio. Tough to get the lighting right with such a bright backdrop.
It's impossible to see anything
How did this video pass QA? Is this part of scrum to check your work before releasing it?
Looks half assed and last minute
Low quality
Was this video made using scrum processes?
Perfect explanation of what I believe is decent sprint planning session.
The Sprint Goal is a critical focus for the Sprint. The Product Owner should come to Sprint Planning with a Sprint Goal at the beginning. This helps the team select PBI's for consideration. Knowing the initial goal also helps experts see hidden value dependencies or relationships between PBI's that should be included in the discussion. The Sprint Goal may be modified during Sprint Planning to better reflect the specific PBI's and forecast created or even the team's capacity at the time. Ultimately, the Scrum Team would then agree upon the final Sprint Goal.
This happens quite frequently in startups and smaller businesses where the early increments can vary widely depending on the stakeholders involved and the business value targeted.
Thanks Robert. I think we are in agreement, but I am always careful with my language when it comes to ownership of the Sprint Goal. I want to avoid it coming across as the Product Owner pushing a Sprint Goal onto a team, despite best intentions. My wording is generally along the lines of:
A good Product Owner should enter Sprint Planning with a goal in mind. However, this should be open for negotiation with the Development Team based on their input, ability, and capacity. The resulting Sprint Goal is owned by the whole Scrum Team.
Our 'goal' with this video was to cover Sprint Planning in 5 minutes. So nuances like this may get lost.
Thanks Don. Hopefully the Sprint Goal is inspiring or important enough to stop the Sprint from becoming just an execution on tasks. Thanks again for leading the PSM TTT course last year. Hope to cross paths again soon. .... ps - working on a game format to be used as a sprint exercise. Will have to check out more of your games!
Great, good tips, thanks
Its pretty obvious to me now, why the company I am working at fails: not the developer put the tickets from the backlog into the sprints, but the scrum master (that has no clue about programming) because of some deadlines we got. The code is a mess and as a beginner my word is not taken serious, but I am saying for months now that the planning we are doing is wrong because it makes no sense.
Welcome to modern development using cargo cult techniques stolen from a completely different time and culture and industry
Most people just want to follow orders blindly
Given the 12 years of indoctrination that where you are told there is a correct answer and way to do it
Lol
No wonder we have so much trouble with creative process management
Software dev is a creative endeavor, not a manufacturing process
Lol
2020 update:
1.Sprint plan by and for developers
2.Sprint backlog, built by developers and changed by both developers and PO
3.Sprint goal created by the whole Scrum team and committed by developers only
Where's the user feedback? Or is that not part of scrum?
Don, I'm interested in your thoughts about PI Planning (Program Increment). Much of what you describe for sprint planning we do in PI Planning which is where we spend 1 full day planning out 4 sprints, each at 2 weeks in duration. PI Planning is where we allow developers to review the backlog of work, prioritized already by the PO, and pull that work into appropriate sprints. Then we do 1 hour of sprint planning to further refine the work much like how you've described with the pink stickys in your video.
Hi Krisin,
PI Planning is a SAFe event, where multiple teams must get together to coordinate every 5 Sprints or so. I am describing pure team-based Scrum that applies with or without SAFe. Even in a SAFe environment, teams should be doing Sprint Planning each Sprint and what I explain in this video should still apply. The more refinement the Scrum Team does to the Product Backlog, whether in PI Planning or not, should make Sprint Planning a bit easier.
great vid......this was the second posting of this vid, but the first vid said part I....is there a part 2?
Regarding the last item - Sprint Goal, will you please provide us with some examples?
Don - do you have any more of these types of vids? Very helpful and practical!!!
Thanks!
Sorry for the confusion Robert. The original post was incorrectly posted as a Part 1, hence the repost as standalone. Here is a great blog that focuses on Sprint Goals. www.scrum.org/resources/blog/getting-done-creating-good-sprint-goals
Excellent video!
When is the architecture decided that allows for the maximum flexibility for the unknown needs?
Thank you Sir!!!
Great video! Any recommendations on apps that allow for collaborative sticky note type planning?
Miro!
What happens with all the sprint backlog items after the sprint is closed? Where do you keep the post its so that the connection between them and the product backlog item doesnt get lost?
Quick question: let's say after a sprint, there is a user story with a story point of 13 that is 80% complete (it will not contribute to the velocity of that sprint); therefore, this requirement needs to be completed in a future sprint. My question is this: do you move that story in the next sprint with the same story point? Or do you move it to another sprint and lower the story point since the amount of work remaining is just 20%. Or do I move it back to backlog, include it in the refining and change the story point there, then move it to the next sprint? Thanks!
Hi Taffy, if I am working with story points, I like to keep it simple. Move it to whatever Sprint makes the most sense and 13 points gets added to that Sprint's velocity, even if most of the work was done in an earlier Sprint. It all works out in the end. The average stays the same. If anyone asks why that Sprint's velocity is higher, we have a story to tell them.
If we start trying to divide points out between Sprints, we kinda lose the plot of Scrum and it could encourage behavior that goes against the Scrum values.
Hope that helps!
Hi. I love the part about letting the developers move the items from product backlog into the sprint backlog. However, there might be times that there are priority items. What's the best way to treat these cases without affecting ownership /accountability?
Coach Rye they must not have a negative impact on the Sprint Goal and should be discussed with the Product Owner. Only the Product Owner can decide on Product Backlog priority
what about estimation of hours for a task or story in this meeting and sprint burndown chart? don't you do them?
Hi Kranti,
Here is what I have noticed and learned over the years:
I used to do estimates of Sprint Backlog items, but eventually realized they were a waste of time. We only really care about when something is done. Saying that your 6 hour task is now 4 hours is not an accurate reflection of reality. The reality is that you still don't know. I also saw trends of 'tasks' dropping to one hour and then staying like that for days. Again, not an accurate reflection of reality. It should be more binary. Is it done or not? If you still want to use Sprint burndowns, consider just counting the SBIs instead of adding up hours. Then burn down when a 'task' is complete. It is just as (if not more) accurate.
Hope that helps. Again, this is just my experience. Others may find hours helpful. I have not.
@@DonMcGreal Yep, Thanks McGreal, Mike Cohn also said, some teams don't breakdown stories to tasks and give estimates in hours also...By the way, SBIs means story breakdown items or tasks?
@@krantimadineni585 Sprint Backlog Items. Generic way of describing broken down stories. They may be technical tasks or just smaller stories. Scrum is silent on what to break them down into. Just that they are smaller than the items on the Product Backlog.
Working with a whiteboard is perfect, how would you recommend doing the same process when everyone is working remotely?
there are many remote board and backlog management tools that we use including Trello, VersionOne, etc.
Check Jira we are using it, so far it's a great software.
what happens when some teammembers run out of tasks during the sprint? in our team it is not realistic that a db-guy starts doing javascript stuff... or that a UX/graphics designer suddenly tries to do sql-tasks...
They can always pull in more work during a Sprint from the Product Backlog. Not all work has to be pulled into the Sprint Backlog during planning and if your PO prioritizes the Product Backlog, there is always more than can be pulled in.
@@ScrumOrg thanks for your answer... hmm but we still face then the problem that the new item might need additional work done from other (still busy) teammembers.. or that the new item cannot be finished until sprint-end. would that be still ok? could we see it as "preparation for next sprint" or as optional story in this sprint?
@@5kyn3t I think it can be seen as what is most valuable for the Product Owner vision to invest the team members resources in either Preparation/Spikes for next Sprints or try to refine more some tasks in order to be as independent as possible if they can be picked up lets say from the UX/UI. Maybe UX/UI could help in testing the product being developed during the sprint, help the testers if nothing is yet ready to be pulled in. Maybe they can help the organization with some global tasks. I think that by talking with the Product Owner some great ideas will come out!
With nov20 guide we can put the goal at the start of the video, not the end. 😉
This guy really likes the word Facilitate.
audio is still broken , only in one earphone
Don, are those green cards actually Epics?
No they are not epics those are stories from the product backlog which the dev team has to work on for the sprint.
Backlit 3:15 so there is no clear visualization
3:37 i cant see shit
4 hours for each team?
Sprint Planning is done at the Product Level. So if you have multiple teams working on a single product, then per team and remember, that is the max. Time-box = maximum time, not fill the amount of time. It can be done more quickly... Remember that you only need enough work to get started and the Sprint Backlog will evolve as you learn during the Sprint.
I don't really understand the point. Everything is in bug tracking system anyway. Consider GitHub. Every item has its own ticket. What prevents the product owner from looking at these in real time? Cannot they be assigned on the fly? In this video you don't even say what the project is about, or why you think that your proposed meeting agenda fits this particular endeavor. Do you think that sticking cards to a window and potentially leaving them there for two weeks is an alternative to online bug tracking system? If the stickers can be moved only by developers, then what is the role of Scrum Trainer in the first place? What does your role contribute to the project?
With all due respect, there are some key elements missing here
1. PO & team defines the sprint goal at the beginning of sprint planning
2. Team picks work items from product backlog to meet the sprint goal
3. Sprint goal serve as north-star and team's capacity/velocity provides the guardrail for sustainable work pace
Nothing is missing. He gave the basics of a Sprint Planning. If you feel it should be more in depth, please provide a link with your in depth tutorial.
What did you say the name of your channel is? What's the title of your video that provides what you felt was missing from this video?
For the love of my bleeding ears, please pan the audio a bit better.
Otherwise, good video.