Scrum is one of the development methodologies which provides a framework for Agile mode of development. Scrum defines the roles, responsibilities and the process to follow
Scrum Roles
In Scrum, there are just three roles. the Product Owner, a Scrum Master and The Team
The Product Owners responsibility is to identify requirements, prioritise them such that the highest priority ones are at the top of list and the least priority ones are at the bottom of the list. PO is the sole person responsible for the ROI
The Teams responsibility is to develop the features that they committed to and meet the quality requirements. Teams are usually 5 to 9 members and they are cross functional i.e. the team comprises of programmer, validator, UI expert or whoever is necessary for successful completion of the Sprints. The team is also self organising with a high degree of autonomy
The Scrum Masters responsibility is to ensure the process of scrum is followed religiously. He/she protects the team from outside interference, helps removing impediments and guides the Team and PO on the Scrum Process
Scrum Framework
Now that we understand the roles, let us look at the Scrum Framework
To start with, the Product Owner starts creating the Product Backlog. Product Backlog is an ordered list of items that needs to be developed to complete the product. These could be product features or technical requirements. The Product Backlog Items at the top of the list are more granular, while the bottom ones would be coarser. The coarser ones will be eventually made granular, when the team finishes off with the higher priority ones. The PO is the owner of the Product Backlog Items
The Sprint, which is a time-boxed iteration, starts with the Sprint Planning Meeting of 2 to 4 hours. This is where the PO and the team comes to an agreement on what they would develop in this Sprint. The meeting is split into two parts. In Part 1, the PO explains the requirements that he would like the team to work on and also answer the teams queries. In Part 2, the team does a bottom up estimation and decides how many of the PBIs, they think can be implemented. At the end of the Sprint planning meeting, the team is ready with their Sprint Backlog which is the set of activities to develop & validate the selected PBIs
The Sprints are usually 2 to 4 weeks and ends on the specified duration, no matter how many PBIs are pending implementation. The idea is to ensure a potentially shippable product is released frequently
During the Sprint, the team does a daily scrum meeting where everyone in the team meets everyday at the same location at the same time. In this meeting, each of the team members appraise the rest of them on “What they did yesterday”, “What they did today” and whether they are facing any issues. The intention is to appraise everyone on whats happening and bring in accountability. Typically the stand-up meeting should not exceed 15 minutes
At the end of each day, the team enters the remaining hours required for them to complete their remaining tasks. This is plotted along the timeline and this chart is called the Sprint burndown chart. It provides a visual view on how much work is pending and is useful for the team as well as the external stakeholders in assessing the risk
During the Sprint, the team members also spend around 5 to 10% of their current Sprint time in refining the PBIs for the upcoming Sprints. This helps the team in familiarising with the next set of requirements as well as giving inputs to the PO
Towards the end of the Sprint, the team does a Sprint Review, where they demonstrate the developed features to the PO and stakeholders. This helps the PO and stakeholders to see the working product and give feedback. Basically this is the inspect & adapt time for the product. The feedback is added as items in the Product Backlog and prioritised
Further to the Sprint Review, the team does a Sprint Retrospective among the team members. In the Sprint Retrospective the team looks back at the process and ask themselves on what practices need to be continued, started and stopped. This is the inspect & adapt time for the process. The actions from this meeting is incorporated in their next Sprint