Over the years our team has gotten good at grooming and splitting up tickets, at estimating individual tickets and keeping a steady Sprint velocity.
Each 3 week Sprint we deliver what the team commits itself to.
However on a macro level we fail spectacularly. Initial Roadmap estimation of how long new features take are way off. A new feature should be ready in 3 sprints.. make that 6. This milestone should be reached in 2 sprints.. Make that 4.
It often comes down to hidden requirements that are discovered midway or prototypes that get into feedback loops with stake holders and take much longer then expected. Compared to those problems, we Rather seldomly we hit unexpected technical problems that prolong a project (but of course this happens too)
This here is why requirements need to be use case oriented, not code oriented. “I want to be able to look at my user profile” not, “I need to click on my user profile picture and navigate to a page displaying the following ten items...”
There needs to be room to deliver the value that can take on that uncertainty. It’s a good thing when an engineer can take a look at the use case and have options for how to deliver it, if you hired for that.
Does the roadmap include 1 sprint blocked off for unknowns for every 1 sprint that is full of known tickets (actual ratio should be determined empirically for your team)?
Each 3 week Sprint we deliver what the team commits itself to.
However on a macro level we fail spectacularly. Initial Roadmap estimation of how long new features take are way off. A new feature should be ready in 3 sprints.. make that 6. This milestone should be reached in 2 sprints.. Make that 4.
It often comes down to hidden requirements that are discovered midway or prototypes that get into feedback loops with stake holders and take much longer then expected. Compared to those problems, we Rather seldomly we hit unexpected technical problems that prolong a project (but of course this happens too)