How to approach story point estimation with advent of AI Dev acceleration tools?
Our dev team is using a very powerful AI-driven coding tool called Cursor on our current project. As this was their first time using this tool, we really did not know how much it would accelerate the work and, even more specifically, if it would be more powerful for different types of build - e.g. it seemed most powerful when coding for front-end, fairly powerful for web search functionality and DB loading/mapping, and similarly powerful for architectural integrations (initial code was great start but needed lots of manual review and revision to get what we wanted).
Not fully knowing what to expect, we began our first 2 sprints estimating stories based on our traditional approach to coding but quickly found out each of our 3 team members was dramatically more productive using Cursor than using traditional approach. We continued estimating story points per our past understanding in subsequent sprints but ended up adding huge amounts of scope to each sprint to utilize the increase in capacity. By the last sprint of our project, we were able to (nearly) complete over 150 points of work with our small team.
My question, then, is how do we reconcile estimation with our dramatic increase in capacity? I'm assuming this must be something others are beginning to experience, as well.
There are a couple of ways to think about this.
One way is to think about what a story point is. When teams use story points, they measure the relative effort needed to complete work. Either you need to recalibrate effort against a baseline, or the story points completed per Sprint will increase significantly. Either or both approaches would work, but if you change your baseline, you may not be able to rely on past data to continue forecasting.
The other option is to move away from story points. An emphasis on refining the backlog so each item represents the smallest valuable unit of work and measuring throughput and cycle time is often more informative and helpful for forecasting. It also removes questions about what to do when it starts to look like when outside factors change the effort or complexity of work, allowing the team to focus more on value delivery rather than estimating.
The AI tool seems to be quite efficient in some ways. How effective is it at inspecting, adapting, and revising the forecast of work on a Sprint Backlog so the Sprint Goal is better met? How effective is it at refining a Product Backlog, or at challenging and improving the Definition of Done?
If human effort is still required to do these things, now the Developers have more time to do so.
Who does the work (Person A, Person B or AI for that matter) should not be a criteria for assigning story points. The AI tool seems to me helping the team in speeding up the work so they are in a position to pull more work into the sprint which is great.
The best way is to use the empirical approach and monitor sprint by sprint and understand your new average velocity and utilize it while planning the sprint.
Be mindful that the commitment towards the sprint goal and value delivery is what matter and not how many story points you have accomplished