In one of my last postings I compared the different SDLC methodologies, but Scrum has been successful for me lately so I want to use this post to expand on it a little bit. First, the Scrum methodology is true to the principles of the Agile Manifesto written back in 2001. Second, it can be implemented at the beginning of an effort or in the middle of an effort that is in trouble. And third, it just works! So what is Scrum?
During a “sprint”, normally a one to four week period, the team creates a potentially shippable product (working and tested software). But a sprint does not always have to equal a release – a release could entail the work (features) done in two or three sprints. The features or functionality that goes into a sprint comes from the “product backlog,” which is a prioritized set of user stories of work that needs to be done. What backlog items (user stories) go into the sprint is determined during the sprint planning meeting. During this meeting, the Product Owner informs the team of the items in the product backlog that she wants completed. The team then determines how much of this they can commit to during the next sprint. During a sprint, no one is allowed to change the “sprint backlog” – the requirements are frozen for that sprint. After a sprint is completed, the team demonstrates the use of the software.
A key principle of Scrum is that customers can, and will, change their minds about what they want and need, and that changes cannot be easily addressed in a planned manner. Scrum accepts that customer change cannot be controlled and focuses instead on maximizing the team’s ability to deliver quickly and respond to emerging requirements.
Some important point to remember are:
All user stories need to be broken down to take between 1 to 16 hours (fewer hours is better – I find the the most you really want a task to take is a day)
Don’t put a user story in the product backlog unless it has an estimate. All user stories have to have an estimated LOE!
Testing has to be included in the sprint
Work in progress (WIP) is BAD! In general it is better to have multiple developers knocking out a task than to have them all working on separate tasks for multiple days. You don’t want to have a bunch of tasks 85% done! A user story is either done 100% or it is not done, ie 0%. Nothing in between!
Burn down should be posted and visible to everyone. You may need to track a sprint burn down and a release burn down.
If a user story is too unknown you need to create a spike item (a time boxed task to do the R&D to better understand the task). That spike item will become a task assigned in a sprint.
Daily Scrum meetings and the Scrum of Scrums meetings should not take more than 15 minutes after a team is working well
No meeting should take more than 4 hours (from my personal experience I’d say 2 hours honestly). Even the demo should be able to be done in less than 4 hours.
There are no meetings for meeting sake in Scrum. Such a nice change!
Before the Sprint starts there is a Sprint Planning meeting to determine what features from the product backlog will be addressed in the sprint (these features move to the Sprint backlog).
During the Sprint there are two daily meetings; the Daily Scrum and the Scrum of Scrums. TheDaily Scrum happens everyday at the same time and same place. The Daily Scrum is used to allow the team to answer three questions:
What did you do yesterday
What are you planning to do today
And do you have any issues in your way
The goal is to have this meeting in 15 minutes or less, so any real issues should be discussed with the Scrum Master before the meeting.
The Scrum of Scrums allows all the Scrum teams to come together and is normally after the daily Scrum. A representative from each Scrum team comes to this meeting and answers four questions:
What did your team do yesterday
What does your team plan to do today
Do you have an issues
Do you foresee your team creating any issues for another team
And finally, at the end of the sprint, there is the Sprint Review meeting where the team demo’s to everyone the working software. And the team also covers what was planned, but not completed in the sprint.
More advanced companies may have a weekly MetaScrum meeting where the Product Owner meets with the stakeholders and answers the same three questions:
What did the teams do last week
What the teams are planning to do next week
And the issues standing in the way
This allows even more communication between the entire organization. Remember the burn down is published and visible.
There are two types of roles, based on the commitment involved, pig roles and chicken roles. The names are derived from a joke about a chicken and a pig opening a restaurant. The chicken only has to provide eggs and may continue their normal activities other than that. While the pig has to be fully committed to the effort i.e. provide the bacon. I personally believe both types of roles are equally important to the success of the release, and the same level of commitment is needed from both pig and chicken roles, but it is a funny joke (if you can take a joke) and it was a great title!
The Pig Roles
There are only three roles on the Scrum team – the Product Owner, the Scrum Master, and the Team.
The Product Owner represents the business. She should be the voice of the customer. This role writes the user stories (use cases), prioritizes them, and puts them in the back log. The Product Owner is responsible for the ROI of the product.
The Scrum Master is not the manager of the team (there are no managers), but their job is to make sure the Scrum process is followed and address issues that would keep the team from delivering the sprint.
The Team is everyone else; normally comprised of less than 10 people this group is responsible for doing the actual work (design, develop, and test). A team will have Architects, Developers, Analysts, QA Testers, etc.
The Chicken Roles
This is everyone else; all the Stakeholders. The Stakeholders are the customers and other people that benefit from the final release. They justify the expense of doing the project. They are only involved during the sprint reviews. They may come to the daily Scrum meeting but only Pigs can speak.
Industry standards show most businesses can obtain a 20% cost savings by out sourcing to India. Jeff Sutherland has stated that implementing Scrum can show an improved efficiency of between 100% to 400%. In his presentation at Google he quoted an improved efficiency of 240% at his last company. And he has shown benefits to distributed teams and teams of up to 600 developers – so you can’t tell me Scrum doesn’t scale!
This entry was posted on Monday, January 11th, 2010 at 9:53 pm and is filed under Management. You can follow any responses to this entry through the RSS 2.0 feed.
Both comments and pings are currently closed.