I think a lot of these arguments applied solidly 5-10 years ago, but today teams can use AI to perform highly detailed estimates in seconds, and ultimately time is money - every effort estimation system ultimately boils down to hours paid per developer, whether we like it or not.
Yeah I always have this problem with Story Points and teams. Especially when Story Point is given as an estimate of effort, rather than complexity. Complexity can be data driven - issue X is adding 3 classes, some unit tests and updating a building script, issue Y is a small edit to a single class and fixing a couple of unit tests if they become invalid. Clearly X is more complicated, objectively, than issue Y, but if you ask about effort, while the same is true, how a team considers the effort between X and Y will be different from one developer to the next, so effort based conversations yield responses like "It's a 5 if I do the work, but a 2 for Jim." which is not far away from, "it will take me 4 days and Jim less than 2". I also don't know why you wouldn't deconstruct? a story to understand what is inside it, if you don't understand the story from a point of view of Definition of Ready, how can you estimate the complexity (or effort if you must) vs another story? If you don't know what's involved, what's the estimate based on?
Hi BovineOx, firstly my apologies on the delayed reply. Those are excellent questions and I'll try my best to answer them below. There is an assumption that the team has some idea of what’s involved based on their experience and what they know. If they have absolutely no idea what’s involved an Agile team will typically start with some research or create a Proof of Concept before applying a broad Story Point estimate to the implementation. It’s also important to remember that an Agile team should be continually refining their Product Backlog Items and in turn their estimations. For example, a single Product Backlog Item that was given 100 points might be broken down into smaller Product Backlog Items, and further detail gathered based on priorities. I.e. the higher priority items would have more detail gathered (i.e. DoR criteria), where as the lower priority Product Backlog items may be left fairly vague (until they become a priority). In case you haven’t seen it, I do have a video on that topic :) here it is: th-cam.com/video/hUhSpY1W6nk/w-d-xo.html I hope that makes sense, but if not or if you have any other questions let me know! Thanks, Richard
Hi sir thanka for the enlightment,but i just wanna ask,why my jira (team managemeny) its showing timeline instead of roadmap?are they different or same
Great pickup Ratel! They are the same - Atlassian recently renamed "Roadmap" to "Timeline". You can find more details using the link below: community.atlassian.com/t5/Jira-Software-articles/New-name-same-powerful-features-Roadmap-is-now-Timeline/ba-p/2348378
@@AxisAgileApps ah thanks!yes i just searched it and start to explore a bit i was worried for this update,because iam thinking that i havent properly start my sprint,and regardinf the user story points,i also think the number might represents the hour that we need to put when it comes to building the feature. But,your explanation complement me,it was way more than hourse but also the complexity,and it varied from all dev skills,iam a new product manager and this thing wasnt my expertise because JIRA was dominantly used by my project manager back then. Once again than you sir for the enlightment
@@anilgondi1008 Hi Anil, Story Points should be discussed during Product Backlog refinement sessions. This will give the Product Owner and team enough time to consider the estimate before the Sprint Planning session. Based on the estimated they might deprioritise, or split larger Product Backlog items.
Hi Vib, yes you can find the playlist for this video series here: th-cam.com/play/PLL-72IrJnz2w_8JyHQVlWSw2w3eP9tL76.html If you're interested in the other playlists we have, you can view them from the channel playlist page: www.youtube.com/@AxisAgileApps/playlists Thanks!
@@AxisAgileApps thanks for this. I have watched multiple videos and it's a great resource to understand agile and scrum and how things actually work..Thanks for making at all public. 😊
Amazing explaination.
Thank You.
One of the few good explanations I've heard - thanks!
Thanks Thyge! Our pleasure :)
Amazing, you're the only one who explained it well so far.
Thanks!!
This was super useful, specially with the examples & showing it on Jira. Thank you so much!!
Thanks Anna! Our pleasure :)
I think a lot of these arguments applied solidly 5-10 years ago, but today teams can use AI to perform highly detailed estimates in seconds, and ultimately time is money - every effort estimation system ultimately boils down to hours paid per developer, whether we like it or not.
Great explanation man. Thank you
My pleasure, thanks!
Very impressive indeed ... many thanks
Thanks Saurabh! Our pleasure :)
I cannot thank you enough❤❤❤❤
Our pleasure Shewaye, thanks!
thank you so much for doing this video!!
Our pleasure Etienne! Thanks for your support :)
Yeah I always have this problem with Story Points and teams. Especially when Story Point is given as an estimate of effort, rather than complexity. Complexity can be data driven - issue X is adding 3 classes, some unit tests and updating a building script, issue Y is a small edit to a single class and fixing a couple of unit tests if they become invalid. Clearly X is more complicated, objectively, than issue Y, but if you ask about effort, while the same is true, how a team considers the effort between X and Y will be different from one developer to the next, so effort based conversations yield responses like "It's a 5 if I do the work, but a 2 for Jim." which is not far away from, "it will take me 4 days and Jim less than 2".
I also don't know why you wouldn't deconstruct? a story to understand what is inside it, if you don't understand the story from a point of view of Definition of Ready, how can you estimate the complexity (or effort if you must) vs another story? If you don't know what's involved, what's the estimate based on?
Hi BovineOx, firstly my apologies on the delayed reply. Those are excellent questions and I'll try my best to answer them below.
There is an assumption that the team has some idea of what’s involved based on their experience and what they know. If they have absolutely no idea what’s involved an Agile team will typically start with some research or create a Proof of Concept before applying a broad Story Point estimate to the implementation.
It’s also important to remember that an Agile team should be continually refining their Product Backlog Items and in turn their estimations. For example, a single Product Backlog Item that was given 100 points might be broken down into smaller Product Backlog Items, and further detail gathered based on priorities. I.e. the higher priority items would have more detail gathered (i.e. DoR criteria), where as the lower priority Product Backlog items may be left fairly vague (until they become a priority). In case you haven’t seen it, I do have a video on that topic :) here it is: th-cam.com/video/hUhSpY1W6nk/w-d-xo.html
I hope that makes sense, but if not or if you have any other questions let me know!
Thanks,
Richard
How is it possible to estimate all Product backlog stories at a Release level in the beginning?
Hi Kitty. sorry for the delayed reply. I like to use James Grennings "Planning Poker Party". Check it out here:
blog.wingman-sw.com/archives/36
Hi sir thanka for the enlightment,but i just wanna ask,why my jira (team managemeny) its showing timeline instead of roadmap?are they different or same
Great pickup Ratel! They are the same - Atlassian recently renamed "Roadmap" to "Timeline". You can find more details using the link below:
community.atlassian.com/t5/Jira-Software-articles/New-name-same-powerful-features-Roadmap-is-now-Timeline/ba-p/2348378
@@AxisAgileApps ah thanks!yes i just searched it and start to explore a bit i was worried for this update,because iam thinking that i havent properly start my sprint,and regardinf the user story points,i also think the number might represents the hour that we need to put when it comes to building the feature. But,your explanation complement me,it was way more than hourse but also the complexity,and it varied from all dev skills,iam a new product manager and this thing wasnt my expertise because JIRA was dominantly used by my project manager back then.
Once again than you sir for the enlightment
@@ratelnsyahla7499 Our pleasure! :)
Who will finalise the story points for the backlog items
Hi Anil, the Story Points are finalised by the developers on a Scrum team.
@@AxisAgileApps sir in which sprint ceremony this story point estimation discussed whether in sprint planning or backlog refinement
@@anilgondi1008 Hi Anil, Story Points should be discussed during Product Backlog refinement sessions. This will give the Product Owner and team enough time to consider the estimate before the Sprint Planning session. Based on the estimated they might deprioritise, or split larger Product Backlog items.
Scrum is astrology for management and CEOs
Hello..is there a playlist for JIRA so that I can watch all videos sequentially
Hi Vib, yes you can find the playlist for this video series here: th-cam.com/play/PLL-72IrJnz2w_8JyHQVlWSw2w3eP9tL76.html
If you're interested in the other playlists we have, you can view them from the channel playlist page: www.youtube.com/@AxisAgileApps/playlists
Thanks!
@@AxisAgileApps thanks for this. I have watched multiple videos and it's a great resource to understand agile and scrum and how things actually work..Thanks for making at all public. 😊