Scrum Practices – Roles and responsibilities
As per the Scrum Charter, the scrum team is composed of 3 roles, namely Product Owner, Scrum
Master and Development Team; each with defined responsibilities and roles. This document
details the processes, duties, and operational scope of activities expected of a Product Owner
(PO), Scrum Master (SM) and Development Team.
The POs are expected to be a part of the overall software development process. Here at Nykaa,
Product Managers/ Program managers/Leads play this role.
Within the Nykaa structure, the Engineering Manager(s) or team Lead(s) may play the role of
‘Scrum Master’; often augmented by the Program Management team.
The development team, usually, is a cross functional group of developers, QAs, designers,
architects, DBAs and any other roles as required.
The scrum ceremonies and roles and responsibilities of the Product Owner, Scrum Master and
Development team are listed below.
Scrum Ceremonies
Event Description Duration Participants
The duration defined to carry out the
Development
Sprint work planned which is to develop the 2 Weeks per sprint
team
increment for the product.
Planning meeting to define the ‘What'
and 'How’ for the sprint. The usual
inputs and outputs for this meeting are:
Inputs:
Product owner
• Product backlog
Sprint Scrum master
• Capacity 2 Hours per sprint
planning
• Velocity
Development
team
Outputs:
• Sprint backlog
• Sprint goal
Daily synchronization meeting for the
scrum team to discuss what has been Scrum master
done to accomplish the sprint goal,
Daily scrum ~30 mins daily
plans for the day as well as any Development
blockers in achieving the goals team
defined.
Product owner
Scrum master
Review for the developed increment as
well as showcase the potentially Development
Sprint review 3-4 Hours per sprint
releasable product increment to the team
stakeholders
Any other
stakeholders
invited by PO
Product owner
Internal meeting of scrum team to
Sprint discuss, what went well, what were the Scrum master
3-4 Hours per sprint
retrospective challenges or things that did not go
well; potential steps to improve Development
team
Product owner
Ongoing, with an
This is required for adding new items
expectation of 10%
Backlog identified during sprint review; Scrum master
of bandwidth by
grooming enriching the existing with technical
each developer pr
details, dependencies, estimates etc. Development
sprint
team
Product Owner
PO owns the product backlog and has the primary responsibility for ensuring that it is updated
and aligned to the product roadmap. Apart from the regular grooming activities, the Product
Owner is also responsible for enhancing the backlog with the inputs from all stakeholders,
creating user stories from requirements, categorizing and organizing, defining urgency, and
customer priority, and maintaining the overall health of the backlog.
The expectations from the PO for each of the above ceremonies are as:
Scrum
Responsibility
Ceremony
Product Owner owns the product backlog and has the primary responsibility for
ensuring that it is updated and aligned to the product roadmap. Apart from the
Product regular grooming activities, the Product Owner is also responsible for
backlog enhancing the backlog with the inputs from all stakeholders, creating user
stories from requirements, categorizing and organizing, defining urgency, and
customer priority, and maintaining the overall health of the backlog.
Based on inputs from different stakeholders, Product Owners analyze the
requirements, create epics under appropriate project, estimate it (using the T-
Epic creation
shirt size technique), collaborate across engineering PODs as well to create
user stories as and where required
An ongoing activity, where the Product Owner collaborates with all
Backlog stakeholders including (but not limiting to) business users, Scrum Master,
grooming Development Team etc to ensure that the epic are always updated with
requisite details and are split appropriately into stories with details
Based on the groomed product backlog, the Product Owner collaborates with
Sprint
the Scrum Master and the development team to ensure that the sprint backlog
planning
contains the critical requests aligning with the team’s capacity and velocity
Objectively review the developed increment as well as take feedback from
Sprint review
external stakeholders which is then incorporated into the product backlog
Collaborate with the scrum team to discuss, what went well, what were the
Sprint
challenges or things that did not go well; along with the potential steps to
retrospective
improve in the next sprint
As the product custodian, the Product Owner needs to ensure that the scrum
Sprint team is following all the processes laid down within the organization, update
governance the Jira tickets which in turn ensures that the correct status/blockers/
dependencies are reported timely
Scrum Master
In a development setup, the key responsibilities of a Scrum Master are to ensure that all members
of the Scrum team are able to work in an optimal fashion; and this is where the scrum planning is
of paramount importance. The scrum master should ensure that all the critical requests are
planned optimally in the sprint while aligning it with the team’s capacity and velocity. The SM
should cater to the fact that the team is neither under committing nor over committing as both
have an adverse impact on the team’s performance.
While planning for the sprint, the SM should consider the issue dependencies as well. The
dependencies could either be intra project (POD) or inter project (POD) and should be
documented in Jira as linked issues with a relevant link type like, ‘Blocks’, ‘is blocked by’. In
case of intra project dependencies, the SM should align the dependent issues to be considered
together or ensure that the blocking issue is planned in a sprint prior to the issue which is
blocked. Whereas in case of inter project dependencies, the SM should connect with the SM of
other project an align the issues ensuring that there is no impact to the development process.
Along with the sprint planning, defining, documenting and keeping focus on the sprint goal also,
forms the key part of SM’s role. Having a defined goal helps the team keep focus and make
dedicated efforts towards meeting the goal. The goal can be documented while defining the
sprint in the Jira project. The SM also enables the team towards meeting the goal, by
collaborating across teams to remove any potential roadblocks.
Another key aspect of SM’s responsibilities pertains to the monitoring and upkeep of sprint
health. The SM should ensure that all the defined process are followed, and Jira tickets are
updated in a timely fashion.
One of the critical reports leveraged for tracking the sprint health is the ‘Burndown Chart’. The
‘Burndown chart’ shows the amount of work that has been completed in a sprint, and the total
work remaining. These helps predict the team's likelihood of completing work in the time
available. These also help track and inform the team of any scope creep that occurs.
The expectations from the SM for each of the above ceremonies are as:
Scrum
Responsibility
Ceremony
Scrum Masters, usually support the Product Owners to analyze the
requirements, and then create epics under appropriate project, estimate it (using
Epic creation
the T-shirt size technique); collaborate with development teams to create user
stories as and where required
Leveraging the groomed product backlog, the Scrum Master collaborates with
Sprint the Product Owner and the development team, ensuring that all the critical
planning requests are consumed in the sprint backlog while aligning with the team’s
capacity and velocity
One of the primary responsibilities of the SM is to assess progress towards
Daily scrum achieving the sprint goal, address any impediments and review and plan their
activities for the next working day
Objectively review the developed increment as well as take feedback from
Sprint review
external stakeholders and help the PO to incorporate it into the product backlog
Collaborate with the team to discuss, what went well, what were the challenges
Sprint
or things that did not go well; along with the potential steps to improve in the
retrospective
next sprint
As the owner of the processes, the SM needs to ensure that the scrum team is
Sprint following all the processes laid down within the organization, update the Jira
governance tickets which in turn ensures that the correct status/blockers/ dependencies are
reported timely, efforts are captured regularly
The key expectations and responsibilities of the development team are as:
1. Help SM and PO in enriching the Backlog. As the primary technical contacts, the onus
of identifying and documenting all technical details related to the requirements rely with
the development team. They should analyze the requirements thoroughly and determine
any dependencies, challenges, feasibility etc upfront.
2. Leverage the cross-functional team. The development team is a group of individuals
cross-functional expertise, which can be leveraged to ensure delivery of shippable
products within project timeline.
3. Ensure Transparency. Provide clear, concise and latest updated and highlight issues and
blockers, enabling the team to help and resolve in a timely fashion.
4. Regular Jira updates. Every member of the development team should ensure that the
Jira tickets are updated regularly, providing accurate details, status changes and even
logging the effort spent on each activity. This helps in enhanced planning leading to
improved sprints.
5. Proper work breakdown. Based on the technical expertise, the development team
should break down the activities into granular pieces, but ensure that each piece is
individually testable, and shippable.
Jira terminologies and process of logging requirement
As Atlassian Jira is the tool used for implementing, tracking, and monitoring the progress, the
below table lists some of the commonly used terms with their definitions.
Jira Term Definition
Identifies a unique initiative which can span across a quarter, multiple sprints
Epic and can have multiple scrum teams collaborating on it. This can be sponsored
by single or multiple business lines.
Indicates activities related to the Epic. In the guidelines defined in Nykaa, each
epic has 3 tasks, Data, Design and Product, which are used to capture the
Task
intrinsic details like detailed requirements, high level design, data policies etc.
These are consistent with the epic in terms of duration and sponsors.
A story is an independent shippable, testable unit of work which is used created
Story by logical break down of the epics. The span of a story is a sprint cycle, which
is about 2 weeks. Each story is aligned to single business line.
For streamline development and testing, stories are divided into chunks of work
Sub-task that can be assigned and tracked individually. These have the same parameters
as that of the story.
Any error, or deviation from expected behavior for an application, during testing
Defect of a story, prior to production release is identified and logged as a 'Defect'.
These usually span the sprint cycle and align to a single business line.
Any idea identified to enhance the story is captured as an ‘Improvement’. These
Improvement
also span the sprint cycle and is aligned to a single business line.
Any error, or deviation from expected behavior for an application, post
Bug production release or during the maintenance phase, is identified and logged as a
'Bug'.
Please note, that these have been contextualized as per usage within the Nykaa setup.
As a Product Owner, one of the key responsibilities would be ensuring that the requirements are
translated and documented appropriately in Jira. Below are the scenarios/ use cases where the
POs are expected to update Jira along with the steps for the same.
Creation of issues on Jira
For all feature requests or new requirements, an Epic should be created under the relevant
project.
1. Navigate to the required project
2. Click on ‘Create’ from the top bar
3. Select ‘Epic’ as the ‘Issue type’
4. Provide appropriate ‘Epic Name’, ‘Summary’, ‘Description’ and other relevant fields
5. Click on ‘Create’
The feature requirements should be broken down into stories that are measurable, testable units
of work, which can be completed within a sprint (usually of 2 weeks duration).
Navigate to the required project
1. Click on ‘Create’ from the top bar
2. Select ‘Story’ as the ‘Issue type’
3. Provide appropriate ‘Summary’ and ‘Description’
4. Update the value for ‘Epic Link’ to associate it with the appropriate epic
5. Click on ‘Create’
Stories are further broken down into subtasks by developers. For eg. A user story can be broken
into Screen design, backend API and integration subtasks.
Dev Estimates and time spent should be added on each of these subtasks. Total Dev Estimate is
summed up and updated on story through automation. QA Estimate is added on story. QA
should add time spent on Story when the testing is completed.