The purpose for this Introduction to Scrum post is to give you a brief and quick overview of Scrum Framework:
Scrum is a lightweight, iterative and incremental agile framework that is open to change. Scrum is the most popular agile framework that is used to manage software projects. It’s a set of practices, roles, events, artifacts, and rules designed to guide a team in executing a project. Its’ essence follows an adaptive mindset that is based on the 4 agile values and 12 principles from the Agile Manifesto.
3 Pillars of Scrum:
Scrum uses an empirical approach to adapt to changing customer requirements. This means decisions are made based on what is actually experienced and observed, rather than large upfront plans that are based on unknown assumptions.
- Transparency – This means visibility to those responsible for the outcome. Examples of transparency include the product backlog, daily standups, retrospectives, sprint reviews, burndown charts, and other information radiators.
- Inspection – This is doing timely checks of how well the project is progressing towards its goals and to detect any deviations. Examples of inspection is reviewing the outcome of sprint deliverables during a sprint review ceremony.
- Adaption – This means embracing change and making adjustments based on what works and doesn’t work. An example is during a sprint retrospective, the teams discusses improvements they would like to make for the next sprint.
Scrum also recognizes 5 fundamental values: focus, courage, openness, commitment, and respect.
Scrum Roles
There are 3 roles in scrum, each role is considered equal to each other. They are committed to the project. The Scrum Team as a whole is self-organizing, cross-functional, optimizes flexibility, creativity, and productivity.
Product Owner
The Product Owner represents the business and is a single voice of the customer. They are responsible for maximizing product value by managing the product backlog and setting the product vision, roadmap, and release plan. The product owner is the single point of contact for any change in scope or requirements and this person also “owns” the product backlog.
Development Team
The development teams is the group of professionals who do the development work each sprint. They are self-organized and manage their own work. Everyone on the development team is equal and shares the title of developer regardless of their skill. Development teams really thrive as high-performing when they become cross-functional.
Scrum Master
The scrum master is the servant leader for the development team and is responsible for enacting and upholding scrum values for the team. They are responsible for removing roadblocks, ensuring the team is functional and productive, and shields the team from external distractions. This person is in charge of teaching Scrum to the team, the stakeholders, and the organization.
Servant Leadership – Delegates, supports initiative, gives credit to others and takes blame, focusses power for interest of the team, emerges from anywhere. Scrum Masters are servant leaders.
Scrum Ceremonies
Release Planning Meeting
The release planning meeting is a meeting to plan for upcoming product releases. During this meeting, the stakeholders plan features and goals to deliver business value for the upcoming release. The business will initially prioritize the order in which each user story will be developed in the release.
Sprint Planning Meeting
The sprint planning meeting takes just before beginning and executing the next sprint. The goal is to plan what and how the team will deliver business value for the sprint. The development team agrees upon the backlog items they are confident they can complete during the upcoming sprint. The team identifies the detailed tasks to complete, identify acceptance criteria according to the Definition of Done. Attendees for the sprint planning meeting are the product owner, development team, and scrum master.
Things to watch out for:
- Drilling into too much detail
- Specifying each feature in full
- Trying to gold plate user stories / requirements
- Not identifying the tasks needed for each user story
- Lack of understanding the plan is frozen and will change
- Lack of participation of required attendees
Important Guidelines:
- Sprint length should be 30 days or less, depending on the size and complexity of project
- Sprint planning is conducted at the beginning of each sprint
- The team should plan the meeting to be around 2 hours for each week of the sprint. So a 2-week sprint should last about 4 hours, a 3-week sprint 6 hours, etc. However, it’s really up to the team to decide.
Sprint Review
The Sprint Review ceremony takes place at the end of each sprint, where the development team shows what was developed to all stakeholders. The Scrum Team shows off and should look forward to it.
The purpose for this meeting is demonstrate that all product criteria has been met according to the definition of done and acceptance criteria. The development team demonstrates working software to stakeholders. The stakeholders will give feedback and the team will outline expected functionality for next sprint.
Recommended Attendees:
- Key management stakeholders
- Project Manager
- PO, SM, Dev. Team, Users, Customers
Potential Roadblocks:
- Not showing the actual functionality (its ok to use PPT)
- Attempting to include last-minute functionality that didn’t meet the acceptance criteria / Definition of Done
Guidelines:
- Held on the last day of the sprint for 1-2 hours
- Invite all stakeholders
- Ensure the Scrum team is present or there is a proxy
- Demo the features on the actual equipment it will function on
- Don’t embellish working functionality
Sprint Retrospective
The sprint retrospective meeting is held on the last day of the sprint and is an opportunity for the team to evaluate their performance of the last sprint. Here, the team evaluates what was done correctly, identifies process improvements for the next sprint, and creates action plans to execute those process improvements. Attendees for the sprint retrospective are the development team, product owner, and scrum master
Daily Scrum
The daily scrum meeting held once a day and is time-boxed to 15 minutes. The purpose for the meeting is for the development team to answer 3 questions:
- What did you do yesterday?
- What will you do today?
- What impediments are in your way?
The daily scrum is very important because it helps facilitate team communications and helps ensure the team is working on / towards the same priorities and end goals.
Another important piece of the daily scrum is the 3rd question: What impediments are in your way. This is important because it informs the team of any roadblocks that impact the team completing the required sprint goal.
The attendees are the development team, product owner, and scrum master. However, this meeting is intended for the development team to communicate with each other and only developers, product owner and scrum master can speak. The focus is on the team and their status
Some things to look out for:
- Only the development team members talk, other people outside the scrum team should not interject.
- The meeting must stay focussed on answering those 3 questions and should not move to general questions or other tangents
- Meeting happens every day, same time, same location and is time-boxed to 15 minutes.
- Product Owner, Scrum Master, and Dev Team must attend or have a proxy backup.
Scrum – Artifacts
Product Backlog
The product backlog is an ordered list of features for the product. The features are represented by user stories. The product owner owns the product backlog and they sort is by priority.
Sprint Backlog
The sprint backlog is a subset of the product backlog that represents a list of the work the development team must complete for the sprint. It is developed during sprint planning, user stories are selected until there is enough work to fill up the sprint capacity in terms of velocity. The product owner selects the stories from the product backlog by their priority. Those user stories are broken down into tasks and given a specific hourly estimate by the development team.
Sprint Burndown
- Displays actual amount of work remaining in the sprint
- Posted in plain sight and updated daily
- Displays the Development teams progress to planned remaining work in the sprint
- Progress is displayed in a downward trend
Release Burnup
- Displays the amount of work complete in a release
- Used to show release progress
- Posted in plain sight
- Shows the development teams progress according to release planning
- Contained in the same document as the product backlog
- Is in an upward trend