Back when I was writing Agile Estimating and Planning (the 2005 book, but now it’s also a video course), I had already been studying and experimenting with estimating approaches for five years. By conducting experiments with various teams, especially those…
I've written before that we should only estimate if having the estimate will change someone's actions. Normally, this means that the team should estimate work only if having the estimate will either: enable the product owner to better prioritize the…
It is good practice to first write large user stories (commonly known as epics) and then to split them into smaller pieces, a process known as product backlog refinement or grooming. When product backlog items are split, they are often…
Ron Jeffries has a new book out, "The Nature of Software Development". I highly recommend everyone read it--in fact, Ron is one of the few people whose every word I recommend people read. I love how he always gives me…
Planning Poker is a simple exercise that delivers outstanding results when performed well. It can quickly lead the team to a shared understanding of the work and an accurate estimate of the size of the work. However I often see…
A.k.a. Story Points allow us to separate Estimation from CommitmentI have known (through experience) for a long time that Story Points are a great way for teams to estimate their work. However it has taken me a long time to come…