Hi richard, I love yout videos as they are very informative. I would like to know how you got 400 sp before without doing any backlog refinement. What if story points change during refinement or planning event? How can we justify release scope and time based one ?
Hi Vikas, great questions. To help a team decide on initial estimates for their Product Backlog items, I like to use an approach by James Grenning (creator of Planning Poker). You can see the details of the approach here: blog.wingman-sw.com/archives/36 It does require the team to have the initial list of Product Backlog items, and the Product Owner needs to be there to describe each item. After this initial session is held and the Story Points applied, the Story Points can certainly change during Product Backlog refinement sessions in future, and that will in turn impact the scope of the release (and when it will be delivered). So expectations need to be managed with stakeholders early, and that's why I like to include the "buffer" value that I gave in the example. The buffer provides some flexibility around how long it's going to take to deliver the release, and to take into account the possibility of scope changing. I hope that helps, and let me know if you have any other questions :) Thanks! Richard
Hi Richard, Thank you for the insightful videos, really gaining a lot of knowledge from them. I had a question. How does a newly formed team conclude on the velocity before starting a sprint in order to plan ahead for the release and to come up with number of sprints required to deliver the entire product backlog?
Great question Ashwini. The ideal situation is to allow the team to run a Sprint so that we have a realistic idea of what they could achieve, but if you have stakeholders who are asking for an estimate beforehand (and they can’t wait just 2 weeks) then the first thing to do is let them know that there is a large amount of uncertainty at this point in time. The team has not worked together before, it is a new project, and there are many unknowns that the team will only become aware of during the course of the project. With that said, we can provide them with an estimate, but we have to factor in the uncertainty. To factor in the uncertainty we will include it in the “buffer” value I mentioned within the video. e.g. we add an additional amount of time to the estimated date to cater for unknowns and fluctuations in scope/velocity that could occur. It’s important to be transparent about what makes up this “amount of time”, such as catering for team members getting sick, disruptions during the sprint, new requirements that need to be added etc So once expectations have been aligned, and stakeholders understand why a buffer needs to be added, I will typically gather the team together to “simulate” a Sprint. We’ll look over the top priority product backlog items (which should be well-understood, sufficiently detailed and appropriately sized) and the team decides what they could realistically get done within a Sprint cycle. With that, you will have an initial Velocity and can go through the calculation. The last tip I’ll give here, is to continually readjust the buffer as the uncertainty begins to drop. You can then continually re-appraise stakeholders with more precise estimates the close your team gets to the end of the project. I hope that makes sense! If not, please let me know and I can clarify :) Lastly thanks so much for checking out the videos and your positive feedback, we really appreciate it!!
Hi. Really like your videos. They are helping me very much. I have a question regarding the release process. How would you proceed if the team is organized in sprints that are 2 weeks long BUT they release every week? I am finding it hard to organize the release and at the moment there is only a release note available with all the tasks that ended up in the release.
Hi @sugarfaryprinces, sorry for the delayed reply! I typically create a Jira "Version" for each release, so in your case there would be a new version each week with all the Product Backlog items that were deployed. It's sounds like that's what you're already doing - is that correct? If so, tell me a little a bit more where you're experiencing issues. Look forward to hearing from you. Richard
Hi @@AxisAgileApps thanks for your response. So the situation that we have at the moment is that these versions that I have in Jira are automatically created from GitHub when code will be sent from Development environment to Integration environment. There is no exact planning ahead regarding what goes in to a release. There is only sprint planning. What can I do to improve that process from a release perspective and have a better overview?
Hi, What if a story is not completed on a release? How can we handle this case in jira? Should we juste update the release or we keep the old and add the new release (like sprint field)? Thanks
Hi Ahmed, sorry about the late reply. If a story is not completed in a release, then it should be shifted to a subsequent release. I.e just update the release it is associated to.
Hi Toufiq, sorry again for the delay. In Jira a "release" signifies the release of a product increment to customers. For example, the "First release" would be the first version of the product given to customers, and the "Second release" the second, or next version that is given to customers. You'll notice that in Jira, the terms release and version refer to the same thing.
Hi richard, I love yout videos as they are very informative. I would like to know how you got 400 sp before without doing any backlog refinement. What if story points change during refinement or planning event? How can we justify release scope and time based one ?
Hi Vikas, great questions. To help a team decide on initial estimates for their Product Backlog items, I like to use an approach by James Grenning (creator of Planning Poker). You can see the details of the approach here:
blog.wingman-sw.com/archives/36
It does require the team to have the initial list of Product Backlog items, and the Product Owner needs to be there to describe each item.
After this initial session is held and the Story Points applied, the Story Points can certainly change during Product Backlog refinement sessions in future, and that will in turn impact the scope of the release (and when it will be delivered). So expectations need to be managed with stakeholders early, and that's why I like to include the "buffer" value that I gave in the example. The buffer provides some flexibility around how long it's going to take to deliver the release, and to take into account the possibility of scope changing.
I hope that helps, and let me know if you have any other questions :)
Thanks!
Richard
Hi Richard,
Thank you for the insightful videos, really gaining a lot of knowledge from them.
I had a question. How does a newly formed team conclude on the velocity before starting a sprint in order to plan ahead for the release and to come up with number of sprints required to deliver the entire product backlog?
Great question Ashwini. The ideal situation is to allow the team to run a Sprint so that we have a realistic idea of what they could achieve, but if you have stakeholders who are asking for an estimate beforehand (and they can’t wait just 2 weeks) then the first thing to do is let them know that there is a large amount of uncertainty at this point in time. The team has not worked together before, it is a new project, and there are many unknowns that the team will only become aware of during the course of the project.
With that said, we can provide them with an estimate, but we have to factor in the uncertainty. To factor in the uncertainty we will include it in the “buffer” value I mentioned within the video. e.g. we add an additional amount of time to the estimated date to cater for unknowns and fluctuations in scope/velocity that could occur. It’s important to be transparent about what makes up this “amount of time”, such as catering for team members getting sick, disruptions during the sprint, new requirements that need to be added etc
So once expectations have been aligned, and stakeholders understand why a buffer needs to be added, I will typically gather the team together to “simulate” a Sprint. We’ll look over the top priority product backlog items (which should be well-understood, sufficiently detailed and appropriately sized) and the team decides what they could realistically get done within a Sprint cycle. With that, you will have an initial Velocity and can go through the calculation.
The last tip I’ll give here, is to continually readjust the buffer as the uncertainty begins to drop. You can then continually re-appraise stakeholders with more precise estimates the close your team gets to the end of the project.
I hope that makes sense! If not, please let me know and I can clarify :) Lastly thanks so much for checking out the videos and your positive feedback, we really appreciate it!!
Hi. Really like your videos. They are helping me very much. I have a question regarding the release process. How would you proceed if the team is organized in sprints that are 2 weeks long BUT they release every week? I am finding it hard to organize the release and at the moment there is only a release note available with all the tasks that ended up in the release.
Hi @sugarfaryprinces, sorry for the delayed reply! I typically create a Jira "Version" for each release, so in your case there would be a new version each week with all the Product Backlog items that were deployed. It's sounds like that's what you're already doing - is that correct? If so, tell me a little a bit more where you're experiencing issues.
Look forward to hearing from you.
Richard
Hi @@AxisAgileApps thanks for your response. So the situation that we have at the moment is that these versions that I have in Jira are automatically created from GitHub when code will be sent from Development environment to Integration environment. There is no exact planning ahead regarding what goes in to a release. There is only sprint planning. What can I do to improve that process from a release perspective and have a better overview?
Hi,
What if a story is not completed on a release? How can we handle this case in jira? Should we juste update the release or we keep the old and add the new release (like sprint field)?
Thanks
Hi Ahmed, sorry about the late reply. If a story is not completed in a release, then it should be shifted to a subsequent release. I.e just update the release it is associated to.
Sorry Im a newbie to scrum. Firstly could you please explain what is a release and why is it used and for what purposes
Hi Toufiq, sorry again for the delay. In Jira a "release" signifies the release of a product increment to customers. For example, the "First release" would be the first version of the product given to customers, and the "Second release" the second, or next version that is given to customers. You'll notice that in Jira, the terms release and version refer to the same thing.
I was just looking at the 0.5 story point estimation. lol
lol thanks for watching @positivemindset723!