Traditionally the software industry has been following “water fall” model of project management where the whole phase of project is divided distinct phases Conception, Initiation, Analysis, Design, Construction, Testing, Production/Implementation and Maintenance. Each of these phase start when the previous phase end. This model of project management was derived from other established industries like construction where it was tried and tested.
However by mid 90’s it was realized that this model was not apt for software industry where requirement changed very fast Agile models of project management were tried and scrum was one of those methodology. The essence of agile model software development was in providing incremental release of the product in a shorter release cycle in an iterative way.
Let’s see in detail what Scrum is:
What is scrum?
Scrum is an agile form of project management framework with iterative release cycles. In a project flowering scrum methodology, there is a fixed short duration release cycle called ‘Sprint’, at end of which a potential releasable part of the product is released. Duration of scrum may range from 1 week to 4 week , however ideal case is 2 week.
The criteria defining whether the product is ‘potentially releasable’ will be there in the ‘Definition of Done’. In other words Definition of done will list the conditions on satisfying which a ‘story’ or statement defining a feature of the product is considered complete and ready for release. Definition of done is agreed upon by the scrum team at the beginning of the project.
A scrum team are members participating in the project and what they do are defined by three ‘Scrum Roles’. The Scrum team Participates in certain scrum ceremonies which form part of scrum framework resulting in creation of certain artifact at the end of each sprint.
Scrum Roles
Scrum is run by a team of members belonging to three distinct roles Scrum Master, Scrum Team or the development team in case of a software project and finally the Product owner. Let’s see each of these roles in detail.
Scrum Master
There will be one scrum master in a scrum team. The scrum master is a facilitator and sees that the scrum team has all the things required to do their work efficiently. Scrum master is an expert in Scrum and also play the role of a coach to train the team to work as part of a scrum framework. It is responsibility of the scrum master to remove impediments that hinders smooth completion of scrum member’s task. Scrum master collaborate between the Scrum team and product owner and ensures that there interests are protected.
Know more about qualities of a good scrum master here.
Scrum Team
Scrum team is the main team responsible for the development the product increment in each iteration or sprint. Ideal size of a scrum team is 7 members plus or minus two. The efficiency of the team tends to decrease as the team grows too large or small. In case of large projects requiring very large team, there is a practice of dividing the team into multiple scrum team and having a scrum of scrum team to coordinate between them.
The scrum team is a flat team and there is no hierarchy of leads, senior or junior team members. All team members are considered equal and are answerable to each other and not the scrum master or the product owner.
It is recommended to maintain the same team members in the scrum team in all sprints of a project. Changing the team in mid-way will affect the efficiency gained by the team working together.
Product owner
Product Owner is a member representing the client and most of the time is a key stake holder of the project. Product owner understands the product requirement well and has the vision of how the software should evolve. Product owner drives the product development by appropriately maintaining a product backlog and sprint back log for the scrum team to work upon .
Artifact
In the course of sprint cycle artifact like Product backlog, Sprint backlog and Product increment will be created. There are also other artifact maintained like burned down chart. Let’s see each artifact in detail.
Product Backlog
Product backlog is a collection of features of the product being developed ordered discerningly based on the priority in which it need to be implemented in the product . Each feature item in the list are defined in form of a ‘user story’ on a story card. Let’s look into the concepts of User story in a bit more detail
User story
User story defines the feature or functionality of an application in a single statement in user’s perspective. A typical user story has following parts
- Target user or user group of the functionality
- What the user wants
- Why is the feature required
Based on these points a typical user story template would be like :
As a < user >, I want < goal > so that < reason >
An example user story for the login feature would be:
As a Registered user, I want to login to the application so that I can view Contents only available to registered users.
Acceptance criteria
An acceptance criteria is an integral part of the user story which defines the conditions to be taken care of while implementing a user story. This could include functional and non-functional aspect of the functionality. For example functional aspect in the login user story we saw above will be:
An appropriate message should be sown if the user enters a wrong password. Account should be locked after 3 unsuccessful login attempt etc.
Non-functional aspects can also be defined in the acceptance criteria. An example for the login user story would be “Login screen should be mobile responsive “
Story point estimate
An estimate is normally provided to the story by the scrum team during the sprint planning meeting. General practice is to provide estimate in form of story points instead of number of hours. Story point quantifies the complexities of the story using a number in Fibonacci series starting from 1 instead of 0 (1,2,3,5,8,13,21,34..) . It is ideal to keep story point of a user story to be at its lower end. To achieve this it is a common practice to divide complex stories with story point beyond a certain number say 13, to smaller stories.
Estimation Process
The scrum team reaches an agreement on what the story point should be collectively.
Planning poker or Scrum Poker is a popular way of doing this. The product owner explains the requirement. Once the requirement is clear to the team all the team members independently do an estimation for the story. Once every one does the estimation they reveal what the estimation number is to the team. The members with the highest and lowest estimation are given a chance to justify their estimate. The process of estimation is repeated the same way until everyone reaches a consensus on what the story point should be. This process is repeated for other stories to be taken up for that sprint.
Sprint Backlog
Sprint Backlog is a subset of Product backlog which is to be taken up for development in the current sprint. Pending stories with the highest priority goes to the sprint backlog. Number of stories to be included in the sprint backlog will depend on its collective story points and the velocity of the team. Velocity of the team is the story points it can complete in one sprint and is gauged from previous sprint’s data.
Product Increment
Product Increment is the Output of a sprint cycle. It is a part of the product being developed which is potentially shipable. A product Increment resulting out of a sprint consist of all items from sprint backlog which satisfy the Definition of Done. Items from the sprint backlog which does not meet definition of done is a spill over and is moved to the product backlog and will be taken up in the coming sprint.
Sprint Ceremonies or events
As part of the sprint framework there are a number of Sprint ceremonies or Sprint Events. These are meetings which the team has to attend. Last’s see them in detail.
Kick off meeting
Project kick-off meeting though not a formal Scrum event, is normally the first meeting of the project which will have all the team members and stake holders. Scrum master presides over this meeting and will give everyone an over view of the scrum process. Expectation on how to conduct various meeting will also be set during this meeting.
Product Backlog Refinement
This is a meeting conducted before a sprint starts to ensure the backlog is ready for next sprint. Product Owner, Scrum master and the team will be involved in this meeting to go through the Product back log items which could potentially be taken up in the coming sprint. Discussion during the Product backlog refinement(PBR) meeting allows the product owner to bring more clarity to the requirement by filling in gaps in the requirement.
Activities of PRODUCT BACKLOG REFINEMENTand RACI matrix
| Key Activity | PO | SM | Dev Team |
| Identify features and break them to stories | R | A | |
| Document Features, stories with acceptance criteria | R | A | C |
| Discuss and explain the features and stories to the team | R | A | C |
| Split or combine user stories as required | R | A | C |
| Finalize priorities for user stories | R | A | C |
| Review and finalize the wireframe | I | A | R |
| Estimate the User Stories(story point) | C | A | R |
Sprint Planning Meeting
A sprint planning meeting is the first meeting in a sprint cycle. In this meeting the Sprint backlog is crated. Story point estimate of stories to be taken up in the sprint is added at this point . If required, the stories are divided into multiple tasks and add in to do list. Scrum master organizes the meeting where Product Owner and The team interact very closely in this meeting
Activities of SPRINT PLANNING and RACI matrix
| Key Activity | PO | SM | Dev Team |
| Finalize the sprint backlog by identifying stories for the sprint based on priority and sprint velocity | R | A | R |
| Define Sprint Goals | R | RA | C |
| Split stories into subtasks | I | A | R |
| Estimate effort for sub tasks | I | A | R |
Daily Stand-up Meeting
This is a meeting of team members that happens on a daily basis. Though the Scrum master coordinates the meeting he/she get involved only if there is any impediment to the team which need to be taken care of. Following are some guidelines to conduct a stand-up meeting:
1. The meeting should ideally end in 15 minutes
2. Each team member will be reporting to the team and not to the scrum master or any other particular member of the team.
3. Subject of reporting should be, what one did last day, what they are going to do that day and impediments if any.
4. Only one person will be talking at a time
5. Everybody should be available on time
6. Avoid distractions like Cell phones or laptop
Activities of DAILY STAND-UP and RACI matrix
| Key Activity | PO | SM | Dev Team |
| Conduct Daily Standup | I | A | R |
| Discuss on what was done last day to meet the Sprint Goal? | I | A | R |
| Discuss on what will be done on the current day to meet the Sprint Goal? | I | A | R |
| Discuss Impediments and work towards removing them | I | A | R |
| Implement any corrective/preventive actions | I | A | R |
Sprint Review Meeting
This meeting happens at the end of every sprint cycle where the team will demonstrate the product developed to the Product owner and other stakeholders including the customers or other interested team. This is the point where the product owner or other stake holders provide feedback on the product developed till then.
All the feedback will be added to the product backlog and will be taken up based on its priority. The sprint review meeting gives an opportunity for the people spending money for the project to gets a gimps of how the product is evolving and check if any corrective action is required to align the product to the changing business need. This meeting takes around 2 hours for a two week sprint.
Activities of SPRINT REVIEW and RACI matrix
| Key Activity | PO | SM | Dev Team |
| Key stake holders are invited to the sprint review meeting | RA | A | |
| Product Owner explains to stakeholders which Product Backlog items have been Completed and what has not been Completed in the sprint | R | A | C |
| Dev team demonstrates the product increment | I | A | R |
| Update the product backlog that better reflect the needs and feedback of the stakeholders | A | C | C |
| Discuss and agree on changes to scope or release timelines | A | C | C |
Retrospective Meeting
Retrospective meeting is convened by scrum master at end of every sprint. This is the point where the team reflects on past sprint. The main points for discussion during this meeting are:
- What went well in last sprint
- What went wrong in last spring and
- Thing that can be improved in the coming sprint
The Sprint Retrospective normally takes around 1.5 hours for a two week sprint.
Activities of Sprint Retrospective and RACI matrix
| Key Activity | PO | SM | Dev Team |
| Inspect how last sprint went with regards to people, relationships, process and tools | C | A | R |
| Discuss what went well, what could be improved | C | A | R |
| Analyze the items, defects to find root cause and corrective actions | C | A | R |
| Create plan for implementing improvements | I | R | R |
Closing note
We saw in this article what scrum is, what various scrum roles are, what are the main Artifact of scrum and sprint ceremonies. We also saw what a user story is and story point estimate. We learned how to do a story point estimation using planning packer.
Sprint or other agile form of project management are now widely adopted in software industry both for small project and large scale projects. It is a win-win situation for both who work on developing a software and those for whom the software is being built.