Scrum is a framework for agile software development consisting of roles, timeboxes and artefacts.
Scrum is not a full-blown process methodology. It doesn’t have precise instructions for every step in the process. It neither is a philosophy or a theory. But what is scrum if it’s not one of these? You could call it a “minimum viable framework” (referring to the Lean Startup’s minimum viable product) for software development.
The elements of the framework are:
- roles: Team, Product Owner, ScrumMaster
- timeboxes: sprint, daily standup, sprint planning, sprint review, retrospective
- artefacts: product backlog, sprint backlog, burndown
Ok. Now you think: “So what? Now I still don’t know what scrum really is!” Fair enough. I’ll try to explain with the simple example of four guys building a website for the shoe repairer down the street.
- The four guys (one guy managing the work, one guy designing, two guys developing) meet the shoe repair guy during a meeting to talk about the new website he wants. This meeting is called sprint planning. The shoe repair guy is the product owner. His task is to explain to the team (the designer and the developer) what he actually wants. The result is a prioritized list of features. The team agrees with the shoe repairer that they know what he wants on his website, and why. This list is called the product backlog.
- The shoe repairer, the manager (ScrumMaster) and the team agree that they will review the work done by the team after two weeks (the first sprint) in a new meeting, the sprint review.
- The teammembers divide the product backlog for the first sprint into a new list they’ll manage themselves, containing all the tasks they’ll have to complete for every feature. This is the sprint backlog.
- Everyday, the team members and the scrummaster meet exactly 10 minutes during the daily standup. Each team member says what he has done since the previous standup, what he will do the next day, and if he has anything that prevents him of doing his work (impediments). The scrummaster has the task to solve all issues or impediments.
- The scrummaster keeps track of progress during the sprint on a burndown chart.
- After the first sprint, the team, scrummaster and product owner gather for the sprint review. The shoe repairer now can validate every feature or not. If not, the feature can be put on the list for the next sprint.
- After the sprint review, the team and the scrummaster evaluate the sprint together during the retrospective. They don’t talk about features, but about teamwork, efficiency,…
- The next week the process starts all over again with a fresh sprint planning.
This are only the basics, but it should give you an idea.
Notice the differences with a traditional project management approach:
- No elaborate documentation or exhaustive project plan.
- Focus on agile values such as customer collaboration, working software and interaction between individuals.