The IKMD Review Production Team has decided to work according to the Scrum framework. The sections below describe the Scrum process and how the team is applying it. Would you rather see a video summing up the fundamentals of Scrum? Click here.
Scrum is an agile process that can be used to manage and control complex software and product development using empiricism; iterative, incremental practices, which can significantly increase productivity and reduce time to benefits while facilitating adaptive, empirical systems development.
- Empiricism is dependent on frequent inspection and adaptation to reach goal, which is why Scrum is based on a sprint with short time frame (2-4 weeks)
- Inspection is dependent on transparency, the process that affect the outcome must be visible to those managing the outcomes.
A sprint is a fixed time period where the amount of work planned is not changed. The essence of sprints is delivering incremental value to the stakeholders allowing feedback continuously and thereby creating the highest value early. The IKMD Review Production team only works on one project/product per sprint to minimize time loss due to context switching.
The following figure shows the artifacts involved in a sprint:
The Product owner is responsible for ordering the work in the backlog according to highest value for the product. This is done by continuously communicating with stakeholders and the development team. The product owner is also present at the sprint planning where he/she presents the sprint goal and explains the value and content of the stories in the top off the backlog. During the demo the product owner accepts or rejects the work completed by the team.
The Scrum master removes obstacles that keep the development team from working at their highest capacity.
The Development team is a self organized team, with the right competencies, which pulls work from the backlog and completes it.
The Product backlog is an ordered list of of work to be put into a sprint.
Work that is added to the backlog should preferably be in the form of User stories. Stories are short, simple descriptions of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system. A story should bring value by its own and typically follow a simple template:
In order to <value>
as a(n) <user>
I want to <action>
Read more about how to write valuable user stories here.
The Sprint backlog is the work the team has committed to for a sprint.
Sprint goals are set to make sure that the individual stories also bring value together. Sprint goals facilitates prioritisation and effective teamwork, makes it easier to obtain and analyse feedback and helps with stakeholder communication (eg. to refrain from adding stories not related to the sprint goal).
During every sprint cycle there are re-occurring ceremonies:
The Sprint planning where the team commits to a certain amount of stories
The Daily stand-up every morning where the team answers the questions: "What did I do yesterday? What am I planning to do today and are there any impediments for that work?"
The Sprint review which includes both a Demo and a Retrospective. The Demo where the work performed during the sprint is demonstrated to stakeholders and the PO signs off either accepting the work done, rejecting it and giving feedback to improve in another sprint (usually the next). The Retrospective allows the team to review and improve the work process.
Grooming meetings are used to prepare the work to be ready for sprint planning. During the grooming meetings the effort needed to take the stories to DONE are estimated to help the PO to prioritize the backlog and the team to choose the right amount of work during the sprint planning.
Definition of Done
To ensure the development team knows what they commit to, the development team, the Scrum master and the Product Owner agrees on what it means that a stories is DONE. Currently the Definition of Done for the IKMD Review Production team is the following:
- All acceptance criteria are met
- The story is tested and reviewed by another team member
- All builds and tests are green
- The story is deployed on a test environment
SCRUM with several products/projects
There are different ways to adapt Scrum to an organization that work on several products and/or projects. This is how we currently work:
Other ways of implementing Scrum with several products/projects
One Product per Product owner per Team working in parallell
Broadening the definition of the product and acknowledgeing that there are two types of stakeholders: Internal (Product Owners, users of "subproducts") & External (End users)