S C R U M
An agile software development methodology developed by Ken Schwaber and Jeff Sutherland in the mid-1990s. Scrum is based on a "Sprint," which is typically a 30-day period for delivering a working part of the system. Each Sprint starts with a two to three-hour planning session that includes the customer (product owner), the facilitator (Scrum master) and the cross-functional team. The customer describes the highest priority in the backlog, and after the team agrees on how much of it to do, it is left alone to do it. To keep the team synchronized, there is a 15-minute meeting every day. At the end of the Sprint, the results are delivered and reviewed, and the next Sprint is started.
In product development, a scrum sprint is a set period of time during which specific work has to be completed and made ready for review.Each sprint begins with a planning meeting. During the meeting, the product owner (the person requesting the work) and the development team agree upon exactly what work will be accomplished during the sprint. The development team has the final say when it comes to determining how much work can realistically be accomplished during the sprint, and the product owner has the final say on what criteria needs to be met for the work to be approved and accepted.
The duration of a sprint is determined by the scrum master the team's facilitator. Once the team reaches a consensus for how many days a sprint should last, all future sprints should be the same. Traditionally, a sprint lasts 30 days.
After a sprint begins, the product owner must step back and let the team do their work. During the sprint, the team holds daily stand up meeting to discuss progress and brainstorm solutions to challenges. The project owner may attend these meetings as an observer but is not allowed to participate unless it is to answer questions. The project owner may not make requests for changes during a sprint and only the scrum master has the power to interrupt or stop the sprint.
At the end of the sprint, the team presents its completed work to the project owner and the project owner uses the criteria established at the sprint planning meeting to either accept or reject the work.
S C R U M - M A S T E R
Scrum is facilitated by a ScrumMaster, also written as Scrum Master, whose primary job is to remove impediments to the ability of the team to deliver the sprint goal/deliverables. The ScrumMaster is not the leader of the team (as the team is self-organizing) but acts as a buffer between the team and any distracting influences. The ScrumMaster ensures that the Scrum process is used as intended. The ScrumMaster is the enforcer of rules. A key part of the ScrumMaster’s role is to protect the team and keep them focused on the tasks in hand.
T E A M
The team has the responsibility to deliver the product. A team is typically made up of 5–9 people with cross-functional skills who do the actual work (design, develop, test, technical communication, etc.)
P R O D U C T - O W N E R
The Product Owner represents the voice of the customer. He/she ensures that the Scrum Team works with the “right things” from a business perspective. The Product Owner writes customer-centric items (typically user stories), prioritizes them and then places them in the product backlog A Product Owner can be a member of the Scrum Team but cannot be a ScrumMaster.
According to original Scrum, Product Owner is in a "pig" role. However, in the context of the Sprint and the daily Stand-Up meetings, the Product Owner is considered a "chicken" since he has no role in the implementation of Sprint tasks.
M E E T I N G S
- D A I L Y - S C R U M - M E E T I N G
- Each day during the sprint, a project status meeting occurs. This is called a “daily scrum”, or “the daily standup”. This meeting has specific guidelines:
- The meeting starts precisely on time.
- All are welcome, but only “pigs” may speak
- The meeting is timeboxed to 15 minutes
- The meeting should happen at the same location and same time every day
- During the meeting, each team member answers three questions
- What have you done since yesterday?
- What are you planning to do today?
- Do you have any problems preventing you from accomplishing your goal? (It is the role of the ScrumMaster to facilitate resolution of these impediments. Typically this should occur outside the context of the Daily Scrum so that it may stay under 15 minutes.)
S P R I N T P L A N N I N G M E E T I N G
At the beginning of the sprint cycle (every 7–30 days), a “Sprint Planning Meeting” is held.
- Select what work is to be done
- Prepare the Sprint Backlog that details the time it will take to do that work, with the entire team
- Identify and communicate how much of the work is likely to be done during the current sprint
- Eight hour time limit
- (1st four hours) Product Owner + Team: dialog for prioritizing the Product Backlog
- (2nd four hours) Team only: hashing out a plan for the Sprint, resulting in the Sprint Backlog
At the end of a sprint cycle, two meetings are held: the “Sprint Review Meeting” and the “Sprint Retrospective”
S P R I N T R E V I E W M E E T I N G
- Review the work that was completed and not completed
- Present the completed work to the stakeholders (a.k.a. “the demo”)
- Incomplete work cannot be demonstrated
- Four hour time limit
- All team members reflect on the past sprint
- Make continuous process improvements
- Two main questions are asked in the sprint retrospective: What went well during the sprint? What could be improved in the next sprint?
- Three hour time limit
A R T I F A C T S
P R O D U C T B A C K L O G
The product backlog is a high-level list that is maintained throughout the entire project. It aggregates backlog items: broad descriptions of all potential features, prioritized as an absolute ordering by business value. It is therefore the “What” that will be built, sorted by importance. It is open and editable by anyone and contains rough estimates of both business value and development effort. Those estimates help the Product Owner to gauge the time line and, to a limited extent prioritize. For example, if the “add spellcheck” and “add table support” features have the same business value, the one with the smallest development effort will probably have higher priority, because the ROI (Return on Investment) is higher.
The Product Backlog, and business value of each listed item is the property of the product owner. The associated development effort is however set by the Team.
S P R I N T B A C K L O G
The sprint backlog is the list of work the team must address during the next sprint. Features are broken down into tasks, which, as a best practice, should normally be between four and sixteen hours of work. With this level of detail the whole team understands exactly what to do, and potentially, anyone can pick a task from the list. Tasks on the sprint backlog are never assigned; rather, tasks are signed up for by the team members as needed, according to the set priority and the team member skills. This promotes self-organization of the team, and developer buy-in.
The sprint backlog is the property of the team, and all included estimates are provided by the Team. Often an accompanying task board is used to see and change the state of the tasks of the current sprint, like “to do”, “in progress” and “done”.
B U R N D O W N C H A R T
The sprint burn down chart is a publicly displayed chart showing remaining work in the sprint backlog. Updated every day, it gives a simple view of the sprint progress. It also provides quick visualizations for reference. There are also other types of burndown, for example the release burndown chart that shows the amount of work left to complete the target commitment for a Product Release (normally spanning through multiple iterations) and the alternative release burndown chart, which basically does the same, but clearly shows scope changes to Release Content, by resetting the baseline.
A Good presentation to get an heads up about the process (SCRUM)
