To succeed in software development in today’s environment we must deliver with speed and flexibility, old methods of developing are beginning to fail due to customer’s requirements and priorities frequently changing.
Scrum is an agile process that enables us to deliver the best possible product in the shortest time.
Scrum promotes rapid software development that is inspected every 2-4 weeks.
The business sets the priorities. Teams self organize and find best ways to deliver.
Software is demonstrated every 2-4 weeks, decisions are made to release, continue or refine.
• Self-organizing teams
• Product progresses in a series of sprints (Fortnightly in our case)
• Requirements are stored in a “Product Backlog” (Pivotal Tracker)
• Full specification unknown
An iteration of work, functionality is implemented during a sprint.
The sprint starts with a one-day sprint planning meeting. Many daily Scrum meetings occur during the sprint (one per day). At the end of the sprint there should be a sprint review meeting, followed by a sprint retrospective meeting.
During a sprint the product is designed, coded and tested. Traditional methods of developing would separate these techniques, scrum teams do a little of everything all of the time.
During a sprint is not the time to make changes!
- Product owner
- Scrum Master
- Sprint planning
- Sprint review
- Sprint retrospective
- Daily scrum reporting
- Product backlog
- Sprint backlog
- • Define product features
• Decide release date and content
• Responsible for profitability of the product
• Prioritise features according to value
• Adjust features and priorities, at every iteration if needed
• Accept/reject work
- • Represents management to the project
• Enacts Scrum values and practices
• Removes barriers
• Ensure team is productive/functional
• Enable close co-operation across roles and functions
• Remove external interferences
- • Cross-functional (Programmers, testers, user experience designers)
• Should be full time
• Self organizing
• Membership should not change mid sprint
The Sprint planning meeting is a negotiation between the team and the product owner about what the team will do during the next sprint.
The product owner and all team members agree on a set of sprint goals, which is used to determine which product backlog items to commit from the uncommitted backlog to the sprint.
Typically the team will then excuse the product owner from the room and break the backlog Items down into tasks. The product owner is expected to be on call during this phase (previously called the sprint definition meeting) for renegotiation or to answer questions that affect the time estimates. This portion of the sprint planning meeting is time-boxed to four hours. Sometimes teams insert placeholder tasks (with rough estimates) for the product backlog items they don’t expect to start working until later in the sprint.
Team shows what the sprint has accomplished; this is often a quick demo of new or refined features. If no visible changes have been made it may be worth explaining that time has been spent refactoring code.
This is an informal meeting that needs minimal preparation, invite the whole team and others.
The sprint retrospective meeting is held at the end of every sprint after the sprint review meeting. The team and ScrumMaster meet to discuss what went well and what to improve in the next sprint.
The product owner does not attend this meeting.
The team should take time to reflect on what is working and what is failing.
What should the team:
• Start doing
• Stop doing
• Continue doing
Daily scrum reporting
- • Daily
• Short (15 minutes)
• Can be stand up
This is not a time for solving problems. Helps to avoid further meetings.
Each team member should answer 3 questions:
- 1. What have I done since the last scrum?
2. What will I do before the next scrum?
3. What may stop my progress?
- • The requirements
• A list of all desired work on the project
• Ideally expressed such that each item has value to the users or customers of the product
• Prioritised by the product owner
• Reprioritised at the start of each sprint
The requirements of the system are held in a backlog, this is a prioritised list of work to be completed. These jobs/tasks are made up features, chores and bugs.
The product owner should take responsibility to prioritize the product backlog. During a Sprint planning meeting, backlog items are moved from the product backlog into a sprint.