Dashboard Spy Topic: SCRUM Basics in Under 10 Minutes: SCRUM is one of the best agile development methodologies being used today.
This video is one of the best introductions I have seen on SCRUM. Take a look:
User representative, SCRUM Master, developers, testers, customers, executives, release planning, sprints are just some of the topics covered in the video.
Here’s an FAQ from the SCRUM video:
What do you mean the daily stand-up is not required?
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).
I thought sprints were suppose to be exactly 30-days. Why are you saying 3 to 30 days?
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.
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 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.).
Why are you saying it’s good to have a sprint focused on bugs?
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.