{"id":3441,"date":"2019-12-15T15:16:00","date_gmt":"2019-12-15T20:16:00","guid":{"rendered":"https:\/\/pacemkr.ca\/?p=3441"},"modified":"2024-04-08T16:06:54","modified_gmt":"2024-04-08T20:06:54","slug":"when-story-points-arent-enough","status":"publish","type":"post","link":"https:\/\/pacemkr.com\/fr-ca\/blog\/when-story-points-arent-enough\/","title":{"rendered":"When Story Points Aren\u2019t Enough\u2026"},"content":{"rendered":"

If there is one trend that has surpassed Agile in our profession over the last ten years, I would say DevOps would be a good culprit. As we\u2019ve seen an explosion of tools to implement CI\/CD in our Scrum teams, we\u2019ve also seen some of our Agile practices being challenged by this new reality.<\/p>\n\n\n\n

I would say those practices are the story points\/relative estimation\/poker planning. And I believe it is more than time we look at new techniques to replace them to fit the new reality of Scrum teams who are heavily influenced by DevOps.<\/p>\n\n\n\n

From my experience with story points and velocity, we estimate a product backlog item (PBI) based on the effort it takes us to deliver a piece of functionality to our product owner. We then try to plot a velocity based on a set of PBIs we take every sprint.<\/p>\n\n\n\n

For example, in the picture below, we visualize a PBI worth 3 story points represented with a blue bar. This blue bar contains all the work planned by the development team to complete the PBI.<\/p>\n\n\n

\n
\"\"<\/figure><\/div>\n\n\n

I find this approach less and less beneficial as we move into a \u201cYou build it. You run it.\u201d mentality. As we can now deploy features sooner and faster than ever, it brings its share of new responsibilities for developers. In such a context, I find Scrum teams do more customer support, resolve outages, fix bugs to keep production code going, and monitor operational dashboards of their systems to name a few new tasks they have to tackle.<\/p>\n\n\n\n

What challenges the use of story points, even more, is how the operational tasks of our Scrum teams can be hard to predict. Can we accurately predict how many sales engineers will call you next sprint with customer issues? Can we predict those two rack mounts are about to overheat because a service technician didn\u2019t do his job correctly?<\/p>\n\n\n\n

So while a 3 story points looked like the above picture when we operated in a pure development vacuum, we represent our new unpredictable tasks with red bars, thus extending our original 3 story points.\u00e7<\/p>\n\n\n

\n
\"\"<\/figure><\/div>\n\n\n

So how valuable is our story point system when those red bars keep showing up on our original estimates? \u00a0If this is your situation, you\u2019ve maybe tried doing better estimations or went with #noestimates. If you are still unsatisfied with those previous options, I believe there is a third way where unplanned work is embedded within the actual metrics.<\/p>\n\n\n\n

Flow metrics<\/h3>\n\n\n\n

I believe we are ready to move forward and adopt a third way which is rooted in empiricism. The approach comes from the Kanban community. They are called the Kanban metrics (or flow metrics). I find they are a great set of practices for the Scrum framework, especially when your context is closer to DevOps than pure development work.<\/p>\n\n\n\n

As defined in the\u00a0Kanban Guide for Scrum teams<\/a>, the four basic flow metrics are:<\/p>\n\n\n\n