I want to try and commit a little heresy by talking about story point estimations. Specifically I want to talk about not using them ever again. This is not a call for no estimation, but a fairly different approach. This idea has some problems, is not fully fleshed out, and needs lots of smart people to think about.
In a nutshell, replace story points with a concrete expectation of the business value of that individual story.
This new estimation could be in expected revenue, an increase in some other KPI, or any other measurable impact. So lets look at how Scrum would be with this one change.
Stand-Ups would remain largely unchanged, though I suspect there may be some new urgency and prioritization that happens daily to see that the highest value work is being delivered first. Maybe teams would naturally impose a WIP limit.
Retrospectives would naturally open their doors a bit wider to the impact the team had in the delivery of stories. Not only would they be talking about how they could have improved their ability to deliver the stories, but also how they are going to get better at pruning low-value work, assessing impact and success, and tightening up business level feedback loops (Maybe they would naturally ask that customers be present during reviews now to get quicker validation on the value of the stories?).
Sprint Review would probably be tricky, as stories that were just delivered very likely won’t have the desired impact. However, these reviews can certainly provide insight in to previous sprints’ expectations, as well as talk about how the impact will be assessed at a future date. This all would happen with the typical demonstration of what was delivered and an explanation of how it will likely deliver on the value intended to stakeholders.
I fully admit that this change will likely make planning sessions very unproductive due to teams not trusting their POs with what value has been asserted. I also think that this is actually the right symptom when a team now actually takes on delivering something of value. I have always believed that in Scrum people have responsibilities instead of authorities, but you almost always see POs with complete authority over the product. So, this argumentative phase while teams and POs learn how to communicate and work out what it means to actually discover and deliver value is one that would require an actual Scrum Master, but would yield a team that is fully invested in the impact of this product. Further, I suspect that because there is the normal sprint boundaries, teams will have a more lively discussion around building the simplest thing that can work instead of ironing out all the technical details of the first idea they had.
While not technically a ritual, this change obviously impacts the PO the most. It demands that the PO take more time to think about the overall impact of a story on a business level instead of identifying features. This would likely mean that the PO would need to partner up or make friends with people in UX, BI, and other customers to see what options exist before it is made into a story, and do some fun maths on what a story may do overall. If they wrote a story about a user logging in, they would need to tell the story of not only why a user cares, but why a user caring impacts the business as well. This is is hard, too hard probably. I think this is where movement in the Lean Start-Up community can help. There is admittedly an unspoken hope in this idea that because an assertion has to be made for all stories as to their impact, and it must be transparent and seen in reviews, people will naturally begin to write stories that are smaller in their assertions, and less risky in nature. This would be married perfectly to a culture that values learning, but I am not going to go so far as to say that this change would encourage that culture, only that it could.
Now, I want to play devil’s advocate against this idea a bit and I’d love for others to any way they can. It could be this idea is totally worthless, but there may be something useful as well. Talking about and exploring it will allow whatever good that may be in here to surface.
It could be, but the difference is that DoD and DoR are internal agreements to a team, and this is an external agreement. We’ve all seen teams and POs make concessions to DoD when there are, “Emergencies.” While I fully believe that teams should be empowered to make those calls, I’m also suggesting that this escalation of estimation and value changes the conversation around how and on what grounds those calls get made. It is very different for a PO to say that they didn’t get time to write the stories until just before planning from a PO to say that they didn’t have time to see if there is any value at all to the stories they want a team to build and maintain. DoD could be added to help encourage the best habits around discovery and estimation of that value.
People who think or say this would do well to listen to retrospectives and go to lunch with teams enough to hear how they really feel about the products they are delivering. You’ll probably very quickly find out that a team that is separated from the meaning of their work, oddly, finds no meaning in it. If you can stomach hearing a team expressing sentiments like, “It’s just a job,” or, “I couldn’t care less,” then what does it say about the rest of the organization?
A team can be served well by knowing this information. It can surface some good questions about what changes they can make to deliver differently. Managers who are plagued by trying to answer the question, “When,” would need to be taught to re-frame their questions and needs. I would love to hope and dream that when the team is aligned to delivering the impact and needs of the business directly, the question of, “When,” becomes one that is already aligned instead of being predicated on the idea that completing features will lead to success. I’m not including a rebuttal for using velocity as a prioritization mechanism, because that really is more of an indication of a story having unclear or low value than velocity being useful.
My fantasy for this is that the PO comes to planning with a small backlog of crazy amazing high-value stories. The team begins to talk about how they could get to that value as cheaply as possible, and a technical plan emerges. They can then ask if they are confident they can deliver that plan in the sprint. If they can’t, does it change the priority? Can the team toss more ballast to deliver differently? I don’t know, but these sound like great damn questions to ask. If priority has been clearly identified before planning (I know, it’s a hilarious thought), then the only real question is, “What is the smallest thing we can do to deliver that value?” It really shouldn’t be a huge deal if it does or does not fit into a single sprint.
When teams split stories due to size, they are also splitting value, and often no value is delivered until all of those split stories are finished. Nothing changes there, though tracking the splits becomes more important and is something I don’t see very many people do effectively. Story size is a challenge, admittedly one I don’t have a clear idea on. This is where we would really be reliant on a PO diving deep into things to pull out the most valuable aspects of features to trim away fat. Grooming sessions would help as it allows for early feedback on stories to help raise important questions. Also, I’ve usually advocated that POs get friendly trusting relationships with several other people in UI/UX, BI, Legal, etc to help them work through their very complex job, maybe leveraging relationships like that would help. I’m really not sure.
I don’t know. How crazy is that? I’ve been doing this for years, and never once has a conversation like that happened. I’d love to take part in one though.
I’ve worked through this in my head for a day or so, still very rough, and if it is ever going to be taken seriously it needs a name. Leave any thoughts or feedback you have.
Want to know the essentials for starting and growing your career? I wrote a free email series to help.