I've previously used pizza toppings as sprint names, like Margherita for sprint 1, laying out the most basic stuff, going through increasingly more complex topping styles until we hit a full year of dev marked by quattro stagioni, and finally landing on calzone ("It's a wrap!") for when we finished the work entirely and moved onto something else. That generally amused people (and caused a few light-hearted arguments about what should and should not be considered a pizza topping).
Thanks again for the feedback and watching the channel Jake. Just letting you know both the second and third parts of this series have been published. All the best!
Hi Jananga! My preference is not to vary Sprint durations within the same project as it will make your team's Velocity inconsistent (assuming your measuring Velocity), secondly it can upset the teams rhythm, and thirdly it does make it more difficult for Stakeholders to attend the Sprint Review as it moves around in their calendars, and stakeholders typically have very busy calendars so they may end up not attending. The only time I typically suggest changing a Sprint duration is when a team is just starting off with Scrum, and they're trying to find a Sprint length that is right for them. But once they find that Sprint length, it's best to stick with it :)
Hi Rolemodel99, good question! When you say throughput I'm assuming you mean average number of Product Backlog items a team completes per Sprint. I have seen teams do this and it can certainly work. For it to work well requires the team to split their Product Backlog items so that they are all uniform in size. I also suggest that the size of those items is relatively small allowing for greater precision. It is fairly rare to see teams be able to do this and that's why I didn't mention it, but perhaps it will be an additional video in this series ;) Thanks again for the question and I hope my response helps!
If you are using and Sprint and Fix Versions both then how do you manage things in Jira? Do you release version upon Sprint completion or regardless of Sprint end you can release a version in between?
Hi Muhammad Atif, good question. You can release regardless of Sprint end. Some teams will release multiple times per Sprint, others will release after many Sprints. You can look at Sprints as to help the team regularly inspect and adapt, and does not dictate release cycles. Hope it helps! Richard
Hi @erhkpage6864 sorry for the late reply. I typically like the team to work this out by sending around a spreadsheet as I've shown in the third video in this series (th-cam.com/video/94sqZadKOFI/w-d-xo.html&lc=UgyGn9Yj-65FZTXafNt4AaABAg). Some teams will also do it at the start of Sprint Planning, but I like to hit the ground running with it already prepared :)
Hi Rolemodel99, another good question. A team will only decide on a Sprint Goal towards the end of Sprint Planning if it's dependant upon what they forecast can get done. What's common is for Product Owners to suggest an ideal Sprint Goal at the beginning, but for teams to confirm what's possible at the end. If the ideal Sprint Goal is not achievable, then the Product Owner and delivery team discuss and come to an agreement as to what's more realistic.
Hi Rolemodel99, Product Goals are typically long term objectives that can span potentially multiple releases. For this reason I find the best place to document a Product Goal is not in Jira, but in Confluence (or other knowledge management system of your choice). Confluence is particularly useful because it easily integrates with Jira, allowing you to document high-level business objectives (for reference) and relate them to Jira issues (for tracking). So in other words, Confluence allows a team to see the long-term objective (Product Goal), and how it may have been broken down into releases in Jira, and how each release has been broken down into a Product Backlog.
Hey Samuel, when you say a Sprint calendar, do you mean when your Scrum activities will be scheduled? If so, Confluence is the best place to document that information and share with your team.
Instead of story points or hours, you can just take a certain number of PBIs to a new sprint. Estimations are usually just guesses anyway and in most of the cases developers don't know how much time the story will take. Personally. I would also stop using Jira as it doesn't help with anything.
Thanks Michal, good points. If you go with the number of PBIs just make sure your team breaks the PBIs down so their relatively small and of similar size. Appreciate the thoughts!
Hi there, sorry for the confusion. This first video shows how to setup a Sprint in Jira, and next video (th-cam.com/video/bvKDldShE8A/w-d-xo.html) shows how to add items to the Sprint to create a Sprint Plan. Let me know which steps are unclear and I'll clarify. In any case, thanks for watching :)
Thanks for the feedback Foxy! Perhaps I get a little too passionate about Agile and Jira ;) but appreciate the feedback and I have been told to limit the hand waving by our team here so you will notice it reduce in future videos.
I've previously used pizza toppings as sprint names, like Margherita for sprint 1, laying out the most basic stuff, going through increasingly more complex topping styles until we hit a full year of dev marked by quattro stagioni, and finally landing on calzone ("It's a wrap!") for when we finished the work entirely and moved onto something else. That generally amused people (and caused a few light-hearted arguments about what should and should not be considered a pizza topping).
Hahaha love it!
good idea!
Thank you, Richard. This is the best YT video on planning with Jira! Looking forward to see the next part of the series!
Thanks Jake! Glad you enjoyed it, there's plenty to come :)
Thanks again for the feedback and watching the channel Jake. Just letting you know both the second and third parts of this series have been published. All the best!
@@AxisAgileApps love d video
@@bhlmmfm6592 Thank you!! :)
Thank you so much for the value you give
Thanks Victor! It's a pleasure :)
Awesome content, thanks from Brazil.
Our pleasure Andre! And thanks for watching :)
Thank you for the quality content. Looking forward to new videos 😊
Thanks Uni corn, next one is almost ready :)
Thanks for sharing your knowledge 😊
Thanks again @anandanm2336!!
Great content..waiting for more. Thanks
Thanks Rashmi, more to come! :)
Sprint name - Light.
Thanks for sharing! :)
such amazing presentation and detailed explanation, our sprint name is Coffee, Tea, and sometime Ferrari
Thanks Karzan! And love the Sprint names :)
Thanks for this insightful video
Thanks Hamzah!
Rivers in Texas were used as Sprint Names.
Nice one Melody!
Another amazing video. Shoutout from Sri Lanka 🇱🇰 Can the sprint durations differ from one another in the same project?
Hi Jananga! My preference is not to vary Sprint durations within the same project as it will make your team's Velocity inconsistent (assuming your measuring Velocity), secondly it can upset the teams rhythm, and thirdly it does make it more difficult for Stakeholders to attend the Sprint Review as it moves around in their calendars, and stakeholders typically have very busy calendars so they may end up not attending.
The only time I typically suggest changing a Sprint duration is when a team is just starting off with Scrum, and they're trying to find a Sprint length that is right for them. But once they find that Sprint length, it's best to stick with it :)
@@AxisAgileApps Understood. Thanks!!
@@janangamalshan6236 Our pleasure! :)
only two options (velocity+story points, time)? what are your thoughts on using throughput?
Hi Rolemodel99, good question! When you say throughput I'm assuming you mean average number of Product Backlog items a team completes per Sprint. I have seen teams do this and it can certainly work. For it to work well requires the team to split their Product Backlog items so that they are all uniform in size. I also suggest that the size of those items is relatively small allowing for greater precision. It is fairly rare to see teams be able to do this and that's why I didn't mention it, but perhaps it will be an additional video in this series ;) Thanks again for the question and I hope my response helps!
thank you so much
My pleasure! thanks for watching :)
Awesome content, please share more. Thank you 😊
Thanks Benna, more is on the way :)
If you are using and Sprint and Fix Versions both then how do you manage things in Jira? Do you release version upon Sprint completion or regardless of Sprint end you can release a version in between?
Hi Muhammad Atif, good question. You can release regardless of Sprint end. Some teams will release multiple times per Sprint, others will release after many Sprints. You can look at Sprints as to help the team regularly inspect and adapt, and does not dictate release cycles.
Hope it helps!
Richard
Good presentation, but too many references to other videos, please keep every video complete in itself. Thanks
Thanks S H! Your feedback is much appreciated and has been noted :)
WHEN (in which event) do team determine thier capacity?
Hi @erhkpage6864 sorry for the late reply. I typically like the team to work this out by sending around a spreadsheet as I've shown in the third video in this series (th-cam.com/video/94sqZadKOFI/w-d-xo.html&lc=UgyGn9Yj-65FZTXafNt4AaABAg). Some teams will also do it at the start of Sprint Planning, but I like to hit the ground running with it already prepared :)
Thanks for the amazing content
Our pleasure Otega Otega, thanks!
what is the thinking around adding the sprint goal last? what happens to behaviours of the team when this is added last?
Hi Rolemodel99, another good question. A team will only decide on a Sprint Goal towards the end of Sprint Planning if it's dependant upon what they forecast can get done. What's common is for Product Owners to suggest an ideal Sprint Goal at the beginning, but for teams to confirm what's possible at the end. If the ideal Sprint Goal is not achievable, then the Product Owner and delivery team discuss and come to an agreement as to what's more realistic.
Thanks Axis
Our pleasure Ashish! :)
Arambh (Start), Jyestha (Calendar Month)
What might you suggest to teams that also work with product goals? How might they represent it in Jira?
Hi Rolemodel99, Product Goals are typically long term objectives that can span potentially multiple releases. For this reason I find the best place to document a Product Goal is not in Jira, but in Confluence (or other knowledge management system of your choice). Confluence is particularly useful because it easily integrates with Jira, allowing you to document high-level business objectives (for reference) and relate them to Jira issues (for tracking).
So in other words, Confluence allows a team to see the long-term objective (Product Goal), and how it may have been broken down into releases in Jira, and how each release has been broken down into a Product Backlog.
Best video
Thanks Val!
Good afternoon brother, please where do you create sprint calendar? Is it in Jira or confluence and how please
Hey Samuel, when you say a Sprint calendar, do you mean when your Scrum activities will be scheduled? If so, Confluence is the best place to document that information and share with your team.
Thanks
Thanks Abu Kenan! You are welcome :)
Waiting for the second part
It’s coming soon! :)
Second and third part have been published :) thanks for checking out the channel Ranita!
Excellent!
Thanks Laura! :)
Why don't I have a "Start Sprint" button like you do?
It's most likely you don't have the right user permissions to start a Sprint, or you might not be using the "Scrum" project template.
Instead of story points or hours, you can just take a certain number of PBIs to a new sprint. Estimations are usually just guesses anyway and in most of the cases developers don't know how much time the story will take.
Personally. I would also stop using Jira as it doesn't help with anything.
Thanks Michal, good points. If you go with the number of PBIs just make sure your team breaks the PBIs down so their relatively small and of similar size. Appreciate the thoughts!
My managers don't really like anything original. Sprint 20/10/2023 are used.
Thanks for sharing Sebastian!
Hi there is no connection with this video and next video. where are the middle steps?
Hi there, sorry for the confusion. This first video shows how to setup a Sprint in Jira, and next video (th-cam.com/video/bvKDldShE8A/w-d-xo.html) shows how to add items to the Sprint to create a Sprint Plan. Let me know which steps are unclear and I'll clarify. In any case, thanks for watching :)
Hard to watch that waving hands
Thanks for the feedback Foxy! Perhaps I get a little too passionate about Agile and Jira ;) but appreciate the feedback and I have been told to limit the hand waving by our team here so you will notice it reduce in future videos.
You duuummbassss
Literally had to 1.5x this video
hah thanks @pmanification that's a great tip for all those who find the video too slow. I have tried to speed up my delivery in future videos :)