The first thing to remember is that no process-related activity should be considered an absolute requirement. The only thing that's absolutely required is: SHIP YOUR PRODUCT. And, the goal is: do it ON-TIME!

Project management shouldn't be "religious," where if you don't do X or Y, you'll burn in hell. That's just not how it works with project management. Don't turn the rules you've learned into false moral dillemmas - use them for what they are: generalities and often times a good place to start.

With that said, pay special attention to what I say in the video regarding stand-up meetings...The daily stand-up meeting is 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 (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 and a daily stand-up would be seen as a joke - a red-tape, time-wasting event that the guy who went to a scrum 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 stand-up 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).

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

If somebody tells you that "in 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.

If your project ships a new version of your web site, iPhone App or windows 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, if 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.

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 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 (stability, finishing touches, bug-fixes, etc.).

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 you focus the entire team on just bug-fixes 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.

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 Scrum, such as monitoring progress using burn-down charts.

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 a Window Client, a Web Client, an iPhone client, a Visual Studio Add-in (for developers) while addressing your needs for simplicity, sprints, burn-down charts and release management (not to mention support helpdesk, wiki and much much more).

And of course, the price (free for single-user installs and starting at $395 for teams of 5 users) can't be beat.

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 >>