Scrum- Roles, Artifacts and Ceremonies

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 .


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.


Key ActivityPOSMDev Team
Identify features and break them to storiesRA
Document Features, stories with acceptance criteriaRAC
Discuss and explain the features and stories to the teamRAC
Split or combine user stories as requiredRAC
Finalize priorities for user storiesRAC
Review and finalize the wireframeIAR
Estimate the User Stories(story point)CAR
Legends: R – Responsible, A – Accountable, C – Consulted, I – Informed

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 ActivityPOSMDev Team
Finalize the sprint backlog by identifying stories for the sprint based on priority and  sprint velocityRAR
Define Sprint GoalsRRAC
Split stories into subtasksIAR
Estimate effort for sub tasksIAR
Legends: R – Responsible, A – Accountable, C – Consulted, I – Informed

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 ActivityPOSMDev Team
Conduct Daily StandupIAR
Discuss on what was done last day to meet the Sprint Goal?IAR
Discuss on what will be done on the current day to meet the Sprint Goal?IAR
Discuss Impediments and work towards removing themIAR
Implement any corrective/preventive actionsIAR
Legends: R – Responsible, A – Accountable, C – Consulted, I – Informed

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 ActivityPOSMDev Team
Key stake holders are invited to the sprint review meetingRAA
Product Owner explains to stakeholders which Product Backlog items have been Completed and what has not been Completed in the sprintRAC
Dev team demonstrates the product incrementIAR
Update the product backlog that better reflect the needs and feedback of the stakeholdersACC
Discuss and agree on changes to scope or release timelinesACC
Legends: R – Responsible, A – Accountable, C – Consulted, I – Informed

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 ActivityPOSMDev Team
Inspect how last sprint went with regards to people, relationships, process and toolsCAR
Discuss what went well, what could be improvedCAR
Analyze the items, defects to find root cause and corrective actionsCAR
Create plan for implementing improvementsIRR
Legends: R – Responsible, A – Accountable, C – Consulted, I – Informed

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.