Scrum Master in Under 10 Minutes

What do you mean when you say the daily stand-up is not required?

Pay special attention to what I say in the video regarding stand-up meetings: they are an excellent way to keep communication flowing and can be a key success factor for many teams. However, the key objective here is that communication needs to flow between team members. In many cases, it already flows incredibly efficiently (although I know that's not the case for most teams).

For example, I have been in teams where the entire team works in a single "war room" scenario, often on the same conference table. In such a scenario, communication is already flowing every minute of the day, so the meetings start be seen as a joke—a red-tape, time-wasting event that the guy who went to a scrum master class is making us do.

In other cases, I've seen distributed teams that use tools such as Yammer to communicate what each person is working on in real-time, making a daily standing meeting, something that's not easily possible in distributed teams, an archaic distraction.

However, in the vast majority of cases, I would recommend sticking with a schedule of daily meetings to sync up where everybody is on the development progress. Don't use my video as an excuse to omit daily meetings (unless you already have a communication system that's better than a standup meeting).

I thought sprints were suppose to be exactly 30 days. Why are you saying 3-30 days?

Let's refer back to this rule: nothing should be considered an absolute requirement (except maybe for this rule).

If somebody tells you that "scrum sprints are always x days," thank them for their time and walk away. They are selling you a religion, and all you want to do is to ship software efficiently. The more reasoned approach is to set Sprint durations based on the release-cycle timeframes for a given project.

When your project ships a new version of your website, smartphone app or desktop application every couple of weeks, then how could you have 30-day sprints? You can't and you shouldn't! That's when 2 or 3-day sprints would make sense.

On the other hand, when you're working on a well-established product that ships a new version every 18-24 months, having longer sprints of 4-6 weeks might make the most sense.

Do all sprints in a given project have to be exactly the same length?

Of course not! Generally speaking, it would be best to have same-length sprints (something like 1, 2, 3, or 4 weeks) so that everybody is on the same page. Everybody knows when a new sprint begins (like every Monday) and when it ends (every Friday). It helps the scrum master reduce the need for extra communication.

However, if you're working on a two-year project on 6-week sprint cycles and you're 8 weeks from shipping, it would make a lot of sense to change your sprint durations to 2 weeks so that you can squeeze in 4 sprints before you ship. Each sprint could focus on a different aspect of the system, like stability, finishing touches, bugfixes, etc.

Why are you saying it's good to have a sprint focused on bugs?

This scrum methodology will vary depending on the scrum master. Ideally, bugs are dealt with at the time the feature is originally in development, but there is simply no question that in every software project I have ever seen, some bugs will be discovered by testers or users at some time after the feature is considered complete.

You could consider addressing bugs just like any other item in your product backlog. There is nothing wrong with that. However, if the entire team focuses on just bugfixes for at least one or two full sprints, you might get better results as the goals of every team member will be the same: fixing bugs!

There is a lot of productivity gain to be had when the entire team is focused on the same goal. Having bug-focused sprints towards the end will generally lead to a more polished, stable product.

What about Scrum Retrospectives, Documentation or [fill in the blank]—why wasn't it covered in the video?

There are a ton of best practices in software development that I did not cover in the video. That doesn't mean you shouldn't have retrospective meetings or stop doing code reviews or stop documention practices. That is not why they were omitted! The video is simply focused on the most important features that are unique to the Scrum methodology, such as monitoring progress using burn-down charts.

What tool do you recommend for implementing Scrum?

As founder and CEO of Axosoft, my opinion to this question is quite obviously biased.

With that said, I think you can't find a better tool than Axosoft's OnTime. It's the only product of its kind to offer an amazing web client, plus mobile, a Windows client, and a Visual Studio add-in (for developers), while addressing your needs for simplicity, sprints, burndown charts and release management (not to mention a support helpdesk, team wiki and much much more).

And of course, the price can't be beat. OnTime starts at $29 a month for teams of 10 users and is free for 2 users.

Oh, and we make some amazing free training videos and weekly podcasts to show you all the features of the product.

Learn more about OnTime »

Do you have more training materials like this?

Axosoft offers a FREE 60-minute web-based Using Scrum with OnTime class that is very helpful if you'd like to see how to implement Scrum.