Here are my 4 favorite scrum-activities:
- Sprint Planning meetings
- Daily scrums
- Retrospectives
- The backlog
Sprint Planning meetings
Planning meetings are at the beginning of each sprint. During these meetings the team looks at the most urgent user stories, then breaks them down in tasks, and then estimates the time it will take to implement each user story.
It is fun to get all geared up and prepare for the next sprint. It also requires everybody to participate in the process of estimating, thus requiring everybody to get acquainted with the implementation tasks at hand. It also allows everybody to bring their ideas and creativity to the table.
Daily Scrums
Daily scrums are short daily (duh!) stand-up meetings where everyone on the team…
- says what they did the day before
- says what they are going to do today
- lets know if they’re stuck with something.
When kept short and to the point, these daily scrums keep everyone informed and focused on the right tasks.
Retrospectives
Retrospectives are meetings at the end of each sprint in which the team figures out:
- What went wrong, and should be changed? And,
- What went well, and must be kept?
Thanks to these meetings, you can improve the way the team works. People can vent their frustrations about issues, while those issues can be effectively tackled and solved.
The Backlog
The backlog is the stack of user stories that need to be implemented. During sprint planning meetings, the backlog is consulted to see what needs to be done in the next sprint.
You know those guys and girls that have a thousand ideas every two minutes and then expect you to plan it right away for next week? Well, I fear them no more, I just tell them (honestly, well-intended and -truly- without sarcasm) this:
Yes, we will get to implementing it, but not now. Let us put it on the Backlog, prioritize everything next Sprint, and then if it gets in the next sprint, we’ll implement it with pleasure!
In general
What I really like about scrum in general, is that you focus on the important stuff, and that you can improve the way you work; the build-measure-learn cycles are short and you get to go through them often. You never get stuck in an endless, tiresome multi-year project – at the end of which you typically do one long depressing post-mortem meeting. And that’s empowering!
About Patrice Kerremans
The Backlog as you describe really is just a way of doing decent project management with regard to Change Requests.
Then, as a project manager you will still need to be able to provide an overal planning for the agreed scope. You need to say to your stakeholders: “This project, with this agreed set of functionalities, will be delivered at date X with cost Y.”
How you manage your team, or how your technical team leader does that, is less of a concern to your stakeholders. As long as you keep up to your promises.
That said, I agree that Scrum is an appealing way of getting everyone involved and empowered. And, you don’t wait for the “big verification test” ’till the end, which ensures everybody you’re on the right track.
The scope is fixed, however, the implementation and solutions are maleable along the way. You roughly know how much sprints you’ll need to deliver the project, but you allow for rearranging user stories if needed on a per sprint basis.
Thanks to the sprints, you get early warnings of hidden complexity, underestimated functionalities etc etc. It gives you the possibility of tackling these issues early on in the project and often. You don’t get the typical end-of project rush, where you start de-scoping stuff and throwing quality overboard just to achieve the delivery date.
In my experience it is a little more (sorry for using the word) ‘agile’ than classical projects.
Mind you, it’s not intended for all kinds of projects or organizations.