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 that worked directly for me, I felt I had learned enough to write that book.
Succeeding with Agile - Mike Cohn's Blog
I spoke with a Scrum Master recently who told me his team had nearly doubled their velocity in only two months. Rather than be happy about this, though, he was concerned.
He knew the team had not suddenly become twice as productive. In fact, he doubted they'd actually sped up at all. Yet their velocity showed they had.
Many teams have at least a moderate ability to plan and control their time. They're able to say, "We will work on these things over the coming sprint," and have a somewhat reasonable expectation of that being the case.
And that's the type of team we encounter in much of the Scrum literature--the literature that says to plan a sprint and keep change out.
But what should teams do when change cannot be kept out of a sprint?
In this post, I want to address this topic for two different types of teams:
- A team that has occasional, but not excessive, interruptions
- A team that is highly interrupt-driven
I'm coming to Austin!
I've wanted to offer training courses in Austin for a while, and the time is right. I'll be there for a
The end of an agile sprint or iteration should be a relatively lightweight occasion. After all, it’s something that will be done at least once a month, and often much more frequently than that. So, it’s important that we don’t burden a team with any more process ceremony than necessary. Often a very simple sprint review is all that is needed.
A couple of weeks ago, I participated in a painful sprint planning meeting. You might have been in the same type of meeting. The team was going to great lengths to identify every task they'd need to do in the sprint. And they were debating endlessly over the precise number of hours each task would take.
That level of detail is not necessary.
I've had a handful of emails lately about the difficulty of completing a complex reporting user story in a sprint.
These emails made the claim that perhaps reports were not something well suited for development with agile because some reports are complicated and take more than a sprint to develop.
I'd argue that the opposite is the case. When something...
I completed the world’s shortest hotel stay last week. Ten seconds. I walked into my Marriott hotel room, saw that it had no desk, and immediately walked out.
When I travel, I need a desk. As the owner of a small company, my work never stops. Even when I should be on a vacation, I still spend at least a few hours a day replying to emails and working early in the morning or…
There are, of course, a variety of ways to go about planning a sprint. I’ve written previously about velocity-driven sprint planning and commitment-driven sprint planning and my preference. But regardless of which approach a team takes to sprint planning, there is also the question of how full to fill the sprint.
There are perhaps as many ways to run a retrospective as there are teams to conduct them. I want to describe my favorite way, especially because it's an approach that has stood the test of time, having worked for years with many, many teams.
The Start, Stop and Continue Retrospective
I like to conduct a sprint retrospective by asking team members what they would start,...