Story points had a time and a place. But now we have methods (and Jira plug-ins) to forecast when work can be done, and a way of measuring a teams flow metrics so they can set a service level expectation they are able to meet. It's based on data from their own work, rather than a gut feeling at a point in time.
Have you tried Flow Metrics? What do you love most about the transition away from story points?
I love being able to answer the question "when will it be done", with a probability factor, rather than a hard date. The forecast adjusts as factors change and you're able to keep your stakeholders informed.
Hi @Carolyn McNicoll ,
Personally, I don't believe in any of those attepts, the same applies to the AI attempts. I am making a guess, but I think your projects/programs are not super similar to one another and differ in terms of complexity, uncertanty and other conventional stuff. How can a tool make a valid assumption if in most cases much more context and knowledge exist in the minds than in descriptions, or if you are exploring a new area/domain/technology/concept? From my standpoint, only up to 30% can be calculated by systems/tools provided 70% is specified and carefully outlined in JIRA/Confluence.
For 90-100% calculation by systems/tools, I would only trust those systems that conduct a well-rounded AI analysis of all your environments - PMIS, VCS, CI/CD software, etc, as well as all milestones/stages/gates - starting from business/product management through development, QA, DevOps, SRE. And I don't know a single solution which can do it now - it costs millions and millions of dollars to develop.
That's why in my app I don't even try to do this unless someone convinces me otherwise.
Best regards,
Alexey
I think you’re making a bit of an assumption that these methods are trying to be the whole answer. (AI trying to do it sounds like a nightmare, I agree)
The forecast isn’t meant to replace human context or judgment. It’s a data-backed starting point for conversation.
It doesn't claim certainty and that's the whole point. How can we be as least wrong as possible. by using available data at hand.
When uncertainty is quantified it creates better discussions.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi @Brodie Chivers ,
>I think you’re making a bit of an assumption that these methods are trying to be the whole answer
Maybe partially, but not quite, in my opinion:
>When uncertainty is quantified it creates better discussions.
Agree, but, from my standpoint, with having only tools giving up to 30% accuracy, this is only true if quantified data is prepared not by those tools, but by experienced people. Otherwise you would spend more time analyzing why certain data was included as the basis for an assumption than on the estimation itself.
When experienced people make assumptions they typically use Bayesian reasoning by default, but their accuracy is much-much higher, requiring far less time to comprehend why certain data was taken as basis, from my standpoint.
The probability of a scenario when such software took into the consideration some nuance that you/team didn't account for and that nuance disrupts your estimate of risks/costs/time/etc is negligibly low, from my standpoint.
Best regards,
Alexey
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Carolyn,
I am a big advocate of this method. It's more classic Kanban than it is Scrum. But we also all know that Story points are just a guess anyway. But if you implement your work where the story or task or whatever the work item is as a single smallest deployable item, then all of your work items will be roughly the same size. Then you can measure your throughput of how many cards you complete on a weekly basis over time, get a good average, and then be able to forecast deliverables into the future.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.