I recently emailed everyone who subscribes to my weekly tips a list of suggestions for ways to motivate team members to arrive on time to the daily scrum. For example, many teams have a rule that if you arrive late, you put a dollar in a jar as punishment for being late. Ideally the collected money is donated to a charity at the end of a project or after it reaches a certain amount.
Planning Poker relies on relative estimating, in which the item being estimated is compared to one or more previously estimated items. It is the ratio between items that is important. An item estimated as 10 units of work (generally, story points) is estimated to take twice as long to complete as an item estimated as five units of work.
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.
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 late at night. A desk in my hotel room is not optional.