Intro
The SCRUM method has been developed based on the Agile Manifesto. It is an IT-system development framework with the help of a step-by-step and iterative approach. Instead of extensive analysis, delimitation, and planning at the beginning of the project, agile development is open to change along the way. SCRUM builds on a close involvement of end-users with the frequent feedback loop. The organisational form is cross-organisational, where one or more teams work iteratively around the development of the product. Before a project starts, all known tasks must be registered in a log, called the backlog.
The goal of each iteration is to produce a functioning portion of the end-product. When using the SCRUM method, managers must encourage the staff to work in cross-organisational teams, accountability, and frequent dialogue. Representatives from the business work closely with developers to ensure the final product complies with customer needs and the company’s goals for the final product.
Roles in Scrum
Product Owner: The Product Owner is an expert on the product. His role is daily to help the development team clarify ambiguities concerns regarding the product to be developed. Product Owner is also the connection between the to-do/the business/customer/product stakeholders and the development team.
Scrum Master: Has the responsibility to ensure that the development team can produce without changing the Sprint’s duration. The Scrum Master clears obstacles before they arise, doesn’t matter it is technical, organisational, or collaborative challenges. The Scrum Master focuses sharply on the Scrum Team’s continuous improvement and development.
Scrum Team: Is the Team that does the practical ‘construction work’ (programmers, designers, test resources, etc.). Remember that the Team must include all the necessary competencies to build and deliver.
Artefacts: Epics, features, and User Stories
The first step in the Scrum process is that the product owner defines a vision for the project, ex. to develop a new online banking system for private customers. Implementing a vision requires breaking it down into minor elements or sub-goals that product developers can execute.
The top-level items in the breakdown are Epics, where an epic is a big chunk of work that need to be divided further into smaller parts called features, and at the bottom level, user stories or product backlog items (PBI).
Gradually, the epics are broken down, refined, and prioritised by the business analyst and other business specialists. The outcome of this work is a list of features called a feature backlog. Features are business requirements typically written in a kind of business language and never so detailed that they can be used by IT developers directly.
Features are primarily written in business language, so they need to be broken down and refined one more time. The outcome of this process is a collection of user stories or PBI’s.
User Stories need to be written in a language to discuss and negotiate with the development team during refinement. A Typical User Story is the expression of a user’s needs noted in the form like:
- As a <Role>
- I want <Needs>
- So that I can <a result, something new>
One problem when working agile is getting the proper documentation level for epics, features, and user stories. The problem can only solve this problem through experience. In other words, it is learning by doing.
In Scrum, meetings are held at regular intervals to create regularity and minimise the need for meetings not defined in Scrum. The Scrum Master facilitates all discussions, and all sessions are time-limited. In that way, only an appropriate amount of time is spent planning.
The Scrum Process
Sprint planning meeting
At this meeting, the Scrum Team and Product Owner plan which tasks or Product Backlog Items they will make into a potentially functioning product during the next Sprint. The Product Owner’s job is to announce which Product Backlog Items are most important, and the Team’s task is to estimate and decide how much work they think they can complete during the Sprint. Figuratively speaking, the team “pulls” tasks from Product Backlog to Sprint Backlog, where the active tasks are located.
At the end of the meeting, the Team divides the selected tasks into a first list of “Sprint Tasks” and finally commits to execute the tasks.
If you think this is easy? Then you’re mistaken. It’s one of the trickiest parts of Scrum. The estimation has always been challenging and problematic, and working in an agile setup do make it easier. But the are some tools to be used. One of the most popular methods is planning poker, and it’s straight out of the box. After using it for a more extended period, the Team will be familiar with it and find it fun and valuable. You find more information about using planning poker on the Mountain Goat.
Daily Scrum and Sprint Execution
A daily meeting, also called daily Scrum, is a maximum of 15 minutes of duration where the Scrum Team reports to each other on progress and obstacles.
Usually, the Scrum Master kick-off the meeting by showing the sprint burn-down chart; the chart gives an overview of the Team’s progress. The Team uses the chart to monitor progress when executing in sprints. The burn-down chart will show the relation between hours and work left in the Sprint and help the Scrum Master and the Team focus on finalising the Sprint.
Each team member answers the following three questions:
· What have you achieved since the last meeting?
· What do you expect to finish before the next meeting?
· Do you have any obstacles to be discussed or escalated?
Daily Scrum is not the place to discuss obstacles and other issues; only reporting should occur. If there is a need to discuss something, this is done at a subsequent meeting.
It is always an advantage if the Product Owner participates in the Daily Scrum. On the other hand, it can be a significant disadvantage for the Team Leader or others with authority to participate. It can make them feel “under surveillance” and under pressure to report substantial (unrealistic) progress every day. Personal, I prefer if the Project Owner is there and part of the Team.
The Sprint Review meeting
The Sprint Review or demo takes place at the end of each Sprint. Here development within the past period is inspected, and, if necessary, new items will be adapted to the Product Backlog.
The Sprint Review meeting helps the Product Owner and other stakeholders find out what the Team is working on (i.e., a look back at the Sprint), and at the same time, the Team must find out how the product and the market are progressing. The most important thing about the meeting is an in-depth conversation between the Team and product owner. Everyone at the conference is informed about the current situation and gets and receives advice.
The meeting includes a demonstration of what the Team has finished in the past Sprint. However, this demo should not take the form of a “presentation”, – so no PowerPoints is allowed. Scrum says that the Team should spend as little time as possible on this presentation.
Sprint Retrospective
This meeting is a central part of Scrum. It supports the ability to inspect and customise how the Team is working. In Sprint Retrospective, the Team’s adaption of the Scrum framework is reviewed and customised. The purpose is to:
- Inspect how Sprint has gone about people, relationships, processes, and tools.
- Identify and fix the more important things that have gone well and are possible.
- Improvement’s work as a plan for implementing improvements to how the Scrum Team works.
And again, the Scrum Master has a crucial facilitation role.
Backlog Refinement Meeting
Most Product Backlog ‘items’ usually need further development (sometimes called grooming or refinement), typically because the items are too large to execute in a single sprint or just not fully understood. Therefore, most Teams find it helpful to prepare the Sprint Backlog before the next Sprint Planning meeting.
As mentioned before, large items must be clarified and divided into minor tasks. The backlog refinement meeting is not a standard Scrum activity and is mainly held together within the Sprint planning meeting.
Ending and starting Sprint – a short wrap-up
When a Team has finalised a sprint, they will have to demonstrate the product they have developed for the Product Owner and sometimes key stakeholders. The meeting will inspire the Team in the planning of the next Sprint. But before going that far, the Team will have to evaluate the Sprint just executed.
The discussions at the demo meeting sometimes take some time, and the scrum master must try to keep the schedule; otherwise, there will not be enough time for the sprint planning meeting.
In most cases, the Scrum Master and Product Owner have already discussed and refined the new items for the upcoming Sprint and most cases, a sprint will take ten working days and one day for demo, retrospective and planning.