Most agile teams use a form of relative estimation to size their user stories. The term relative estimation comes from the root word relate. This means that, when teams decide how much effort a given user story requires, they are not really thinking in terms of hours or days but rather about the effort involved in relation to other stories they have done in the past, or maybe even stories they are considering right now.

As a ScrumMaster, your job is to remove impediments and facilitate the Scrum process. But how do you know when an impediment exists? The truth is, the discovery of most impediments will not come from your team or Product Owner telling you about them. You will find them because you see them happening.

The Scrum Guide says that the ideal Scrum team size is between 3 and 9 members. Here’s why: think of a team of two people, you and me. I can communicate with you, you can communicate with me. Pretty straight forward, right? Now let’s introduce another person - we’ll call her Kate. Immediately, there are more lines of communication...

Recently, the Scrum Alliance decided to raise the maximum number of attendees allowed in certification classes to 50 people. The Druckman Company will NOT be teaching classes of that size. In my opinion, that is not a class – it is a seminar. I’ve been to some large seminars that I very much enjoyed. But a certification class and a seminar are not the same thing.

My clients get some very strange ideas about how to choose sprint length. Some seem to think it is extremely important that all the Scrum teams at their company do sprints of the same length. They might even go so far as to make all the teams start and end their sprints on the same day.

In short, yes - absolutely. This is a common question I get from my clients. “We used to have weekly status meetings and now, with Scrum, we have them every day. Can’t we skip a few or just do twice weekly?” When I get a question like this, I can tell that the person asking doesn’t understand the purpose of the daily Scrum. And I will admit, when I was new to Scrum (having come from the world of project management) I fell into this too.

Are there ever times when a waterfall approach to managing projects is a better choice than Scrum? This might surprise you, since I am a Certified Scrum Trainer, but I actually think there are times when a waterfall approach to project management works fine.

As ScrumMasters work to enhance their knowledge of Scrum and help their organizations move towards agile transformation, there is definitely a time and place to use Scrum-specific books to help with that. Books like mine, 30 Days to Better Agile, give specific and targeted advice about how to fix some of the most common problems that occur during…

There are inevitably going to be times when a Scrum team commits to deliver a user story and they do not complete it. So what happens next? The Product Owner rejects the story. It goes back to the Product Backlog and can be prioritized wherever the PO would...

This is a question I get all the time: how can I improve the velocity of my Scrum team? To which I say: Yikes - BE CAREFUL! You are falling into a common mistake: thinking that one of the goals of Scrum is an ever-increasing velocity.