Thanks for the awesome content... I find this content valuable and informative, considering I am new to Agile and currently pursuing a Scrum Master role.
The question remains, how do you split stories with a lot of technical prerequisites that only add value IF the dependent task gets delivered, but if you never get to that dependent task, then the pre-work is of minor value to the end user? For example, our team is working on a story to create a user interface that allows users to adjust certain business rules, but when it was first developed, a lot was made static and is not business configurable. So to accomplish this, the team needs to refactor a lot of data. This makes for a pretty large story. We could split it up so that each item that needs to be refactored is a separate story, but the end user wouldn’t notice the difference if we don’t eventually create the Settings page. Per my understanding, the user story must be valuable to the end user, so technical tasks that are merely a means to an end can’t be considered independent stories. So it seems like a large, multi-part story is inevitable, is it not?
2 года назад+1
Good question. Exactly the dilemma we find ourselves often in. I hope this question gets addressed.
Rather than addressing all business rules at once and splitting it into enablers & a final user story that delivers value. Could the stories be split into smaller business rule configurables? Sorry I do not understand enough about your business to give enough context! Where I work, we would deploy & hide all smaller stories into production that offer value but do not function fully without another. Once the 3-4 stories are complete, we then release all 3-4 stories at once.
2 года назад
@@barcleywest6720 that's also what we do, but that's not was is suggested in the clip, it seems.
I was following much of the content here, but I don't necessarily understand the concept of not letting the estimate leave the room. At a larger company, there are inevitably pieces of the product release lifecycle that are going to depend on some sort of date estimate. (Product marketing motions, other types of contributions to organization-level OKRs, for example.) It's also important to be able to set ambitious goals and achieve them, in terms of features and milestones. So my question is, how can you keep the team motivated by future goals and allow stakeholders to follow progress of features if you don't offer delivery estimates?
Note that _date estimate_ - I prefer the term _forecast_ - does not depend on "estimating". It's common practice to use Story Point estimates to produce forecasts, but it's not the only way: it's been shown that a pure _count_ of stories produces a more accurate forecast. (In other words, estimating produces _less_ accurate forecasts than not estimating at all!)
To understand the total number of stories in our backlogs we would still need to slice all of the stories? Or am I missing something. Love the videos 👍
For forecasting purposes? No, it's not necessary. If feels non-intuitive,, but remember that the data Vasco Duarte used for his research was subject to ZERO preconditions.
Love it, great video and I agree estimates and estimating is evil. Thinking about the way you’ve described story slicing conversations has made me think about it in a way I hadn’t before, thank you.
Nice! So to integrate this idea in my brain I’ll need to set you up with my thinking on refinement/estimation so I can ask the question that comes up for me. I picked up a rad heuristic for the conversation as first “why?” with stakeholders then “how?” with the team. If I’m going to add slicing into that flow, where might you suggest?
You could mix it in with a Three Amigos session: - pick up a ticket - grab a "builder," a "tester" and a "sign-off-er" - talk about the ticket... with the aim of identifying the smallest thing that can be built and tested and signed-off Worth a try?
I get the point that it would be nice to work without the pressure of estimating. But I think that none of the no-estimation advocates would hire a company for building a house that does not give an estimation or fixed price for the cost of the house. I would not pay for a software team that can't give me a rough idea of cost for the features I want.
There's an important distinction hiding here, and it comes down to language. When a builder provides an "estimate", it's a very different thing to the "estimate" that I might provide as a developer. A much closer equivalent (to the builder's "estimate") is the "forecast". Here's why: the cost/week of a software team is constant, so if you know the end date, you know the total cost. So the question becomes: "can we forecast without [agile style] estimating?" And the answer is... absolutely!
How does the builder react if you midway through the project of building a house realize that it's not a house that you need or the end user wants? How does the agile build process solve that? How often does a bathroom turn into a kitchen because of changes in requirements or user testing?
@@GaryStraughan :D If that's true, thank YOU! I'll need this valuable info for my company, were fully embracing Scrumban and forecasting is really important and we need at least some way to do that. Waiting for the secret to be unfolded!
@@Developmentthatpays I can't wait! Currently struggling a bit to have multiple layers of issues in Jira (as we are Splitting the stories, there are too many branches and I can only create 3 layers: epic, story, subtask). What have you been up to all this time?
Time to even things up and talk about the POSITIVE side of estimating. Enjoy!
Please please come back…I can watch you all day😊
You're right: it's been a while.
Thanks for the awesome content... I find this content valuable and informative, considering I am new to Agile and currently pursuing a Scrum Master role.
Wow one of your best vidéo (nice, valuable, smart)
The question remains, how do you split stories with a lot of technical prerequisites that only add value IF the dependent task gets delivered, but if you never get to that dependent task, then the pre-work is of minor value to the end user?
For example, our team is working on a story to create a user interface that allows users to adjust certain business rules, but when it was first developed, a lot was made static and is not business configurable. So to accomplish this, the team needs to refactor a lot of data.
This makes for a pretty large story. We could split it up so that each item that needs to be refactored is a separate story, but the end user wouldn’t notice the difference if we don’t eventually create the Settings page. Per my understanding, the user story must be valuable to the end user, so technical tasks that are merely a means to an end can’t be considered independent stories.
So it seems like a large, multi-part story is inevitable, is it not?
Good question. Exactly the dilemma we find ourselves often in.
I hope this question gets addressed.
Rather than addressing all business rules at once and splitting it into enablers & a final user story that delivers value.
Could the stories be split into smaller business rule configurables?
Sorry I do not understand enough about your business to give enough context!
Where I work, we would deploy & hide all smaller stories into production that offer value but do not function fully without another. Once the 3-4 stories are complete, we then release all 3-4 stories at once.
@@barcleywest6720 that's also what we do, but that's not was is suggested in the clip, it seems.
Story slicing! How brilliant is this idea. Kudos for this great explanation! 👏
Many thanks. You just made my day 👍
Brilliant and Engaging... Love your videos so far!
Thank you! Much appreciated.
I was following much of the content here, but I don't necessarily understand the concept of not letting the estimate leave the room. At a larger company, there are inevitably pieces of the product release lifecycle that are going to depend on some sort of date estimate. (Product marketing motions, other types of contributions to organization-level OKRs, for example.) It's also important to be able to set ambitious goals and achieve them, in terms of features and milestones. So my question is, how can you keep the team motivated by future goals and allow stakeholders to follow progress of features if you don't offer delivery estimates?
Note that _date estimate_ - I prefer the term _forecast_ - does not depend on "estimating". It's common practice to use Story Point estimates to produce forecasts, but it's not the only way: it's been shown that a pure _count_ of stories produces a more accurate forecast. (In other words, estimating produces _less_ accurate forecasts than not estimating at all!)
To understand the total number of stories in our backlogs we would still need to slice all of the stories? Or am I missing something. Love the videos 👍
For forecasting purposes? No, it's not necessary. If feels non-intuitive,, but remember that the data Vasco Duarte used for his research was subject to ZERO preconditions.
Love it, great video and I agree estimates and estimating is evil. Thinking about the way you’ve described story slicing conversations has made me think about it in a way I hadn’t before, thank you.
Nice! So to integrate this idea in my brain I’ll need to set you up with my thinking on refinement/estimation so I can ask the question that comes up for me. I picked up a rad heuristic for the conversation as first “why?” with stakeholders then “how?” with the team.
If I’m going to add slicing into that flow, where might you suggest?
You could mix it in with a Three Amigos session:
- pick up a ticket
- grab a "builder," a "tester" and a "sign-off-er"
- talk about the ticket... with the aim of identifying the smallest thing that can be built and tested and signed-off
Worth a try?
I get the point that it would be nice to work without the pressure of estimating. But I think that none of the no-estimation advocates would hire a company for building a house that does not give an estimation or fixed price for the cost of the house. I would not pay for a software team that can't give me a rough idea of cost for the features I want.
There's an important distinction hiding here, and it comes down to language. When a builder provides an "estimate", it's a very different thing to the "estimate" that I might provide as a developer.
A much closer equivalent (to the builder's "estimate") is the "forecast". Here's why: the cost/week of a software team is constant, so if you know the end date, you know the total cost.
So the question becomes: "can we forecast without [agile style] estimating?" And the answer is... absolutely!
How does the builder react if you midway through the project of building a house realize that it's not a house that you need or the end user wants? How does the agile build process solve that? How often does a bathroom turn into a kitchen because of changes in requirements or user testing?
Its awesome but what about velocity how you want to figure it out
The next video - coming on Wednesday - talks about Velocity.
So if the stories are small why would they need to be estimable? Waiting for the answer for 9 months...
Blimey, was that really 9 months ago! I was so shocked that I spent the last 2 hours writing the next episode. THANK YOU.
@@GaryStraughan :D
If that's true, thank YOU! I'll need this valuable info for my company, were fully embracing Scrumban and forecasting is really important and we need at least some way to do that. Waiting for the secret to be unfolded!
@@KyZa1111 - look out for the first of TWO new videos TOMORROW (7 Dec 2022).
Thanks again for kicking me into action 🚀
@@Developmentthatpays I can't wait! Currently struggling a bit to have multiple layers of issues in Jira (as we are Splitting the stories, there are too many branches and I can only create 3 layers: epic, story, subtask).
What have you been up to all this time?
Great thumbnail image! I have asked myself whether you have a tattoo of a barcode now at the back of your head. ;)
I kinda want one 🤣