Skip to content

Scrum helps produce results with less risk

Posted in Scrum-en

Scum is a way to organise and lead work.

The Scrum team plans each Sprint, which can be 1-4 weeks long. The team’s developers create Sprint plan and implement it.

At the end of the sprint, the team and team stakeholders review the results of the work. After that, the team will evaluate their own success during Sprint. Team implements the necessary changes as soon as possible. Then it all starts again.

Scrum basic pillars


The process and work must be visible to the authors and the clients of the work. At Scrum, decisions are based on: the content of the product and sprint development queue and the Sprint result.


Scrum outputs and progress towards agreed goals are often assessed to identify potential problems. To facilitate evaluation, Scrum offers cadence in the form of its five events.


The Scrum team changes the applicable process or outcome if the result of the Sprint is not in line with the Scrum goal.The team will do the adjustments as soon as possible to minimise anomalies.

Scrum Values

Successful use of Scrum depends on people understanding and adhering to Scrum’s values:


Team members have the courage to do things right and work on difficult issues.


Everyone focuses on Sprint and the goals of the Scrum team.


All team members are committing to achieving the goals the the Scrum team.


The members of the Scrum team respect each other as capable, independent people.


The team and its stakeholders agree to be open to all work and the challenges of doing the work.

Scrum Team

The team includes one Scrum Master, one product owner and developers. There are no other Teams or hierarchies in the team. Team members are a cohesive group of professionals who focus on one goal at a time.

Team members are multi-skilled, meaning they have all the skills needed to accomplish each Sprint goal. They decide for themselves who does what, when and how.

The Scrum team is responsible for all product-related activities such as stakeholder collaboration, testing, maintenance, product development, and anything else that may be needed.

Product Owner

The product owner is responsible for maximising the value of the product. He is also responsible for managing the development queue, which includes:

  • Product goal development and communication
  • Adding tasks to the development queue
  • Refinement and prioritisation of User stories
  • Ensuring the visibility and comprehensibility of the development queue

The product owner and stakeholders agree together what tasks they add to the development queue. However, the product owner is solely responsible for maximising the value of the product.

The product owner should preferably have only one team so that she can handle her responsibilities properly.

Scrum Master

The Scrum Master is responsible for the operational efficiency of the development team. He removes team obstacles if team members are unable to remove them themselves. The Scrum Master also ensures that Scrum events are held on time, stay the agreed length, and atmosphere is positive.

Scrum Master helps the product owner find ways to manage the product goal and development queue. If necessary, he can also guide the entire organisation in implementing Scrum policies.

The Scrum Master should only perform ScrumMaster tasks in order to be able to handle responsibilities with quality. It would be recommended for Scrum Master to have a maximum of two teams in charge. The product owner or team member should not be a Scrum Master.

Development Team

The developers are responsible for the implementation of the planned work. They decide for themselves how the work is done. The team is responsible for ensuring that the work is done in accordance with the Sprint Objective and in accordance with jointly agreed criteria.

The team should be 100% dedicated to the team and its product. Not everyone needs to be 100% employed all the time. It is more important to identify idle tasks than developers.

Why Scrum?

Higher quality

Scrum helps ensure high quality in the following ways:

  • The requirements are defined and specified at just the right time to make the requirements as relevant as possible
  • The team tests their outputs automatically and manually on a daily basis. The product owner also participates in the testing
  • The product owner approves the team’s outputs based on the Definition of Done and requirements acceptance criteria
  • Scrum team and stakeholders review done functionalities at the end of each Sprint
  • After the review, the team goes through things that could be improved such as processes, tools and the work environment

Faster return on investment

Faster returns are achieved by delivering quality products in a dense cycle to customers. Customers and stakeholders can provide feedback after each sprint, allowing the product owner to adjust the content of subsequent sprints.

Better management and lower risks

Projects are in better control because the work is done in sprints of a certain length and everyone knows what needs to be done during the sprint. In a project, everyone needs to be able to easily see what teams are doing and when things will be completed. Team members communicate with each other every day, so bigger hurdles shouldn’t come as a surprise.

The product owner, stakeholder representatives, and customers review the team’s accomplishments at the end of each sprint. In this case, we see concretely what is ready and what is not. It is often easier for customers to give feedback based on a presentation or a working product than to tell the team in advance what they want. Based on the feedback, the product owner can change the content of future sprints.

Scrum events

Better motivation

The development team manages itself with the help of the Scrum Master. They decide by themselves how to do things. Scrum encourages a steady pace of work. Scrum team plans Sprints so that it reaches the goal without overtime.

Better customer satisfaction

The customer will see the results of the team at the end of each sprint and be able to influence the content of future sprints. Because of this, the team always does only the things they want and the customer is willing to pay for. When the customer is constantly involved in the development of the product, it leads to better cooperation and the most satisfied customer.

When Scrum fits?

Scrum is very suitable for complex projects when nobody knows exactly the outcome of the project or how to get there. It is suitable for practically any project that does something unique. It can be a product or a service or something in between.

When Scrum does not fit?

Scrum does not fit very well for maintenance and support tasks. In this case, it is better to use the Kanban model.

Kanban models the workflow, limits the amount of work according to capacity, and optimises the flow of work through continuous improvement.

Transition to Scrum methods

Define the current state

  • Where are we now?
  • Where do we want to be in 6-12 months or two years?
  • Create a vision for the transition to Scrum methods, what do you want to achieve?

Plan your change

  • Where does the ability to change come from? It takes time and money
  • Begin with a single development team, but keep the whole organisation in your future plans
  • Proceed agilely. Task / sprint at a time.

Make the change

Implement the transition one thing at a time, don’t make the changes too big

  • Short-term gains are important
  • The old and the new way of working can live together
  • Measure and collect feedback (for example):
    • Quality (number of defects)
    • Motivation (staff survey)
    • Customer satisfaction (customer survey)


  • There is always room for improvement!
  • PDCA = Plan, Do, Check. Act (and Repeat)

Make sure you succeed

  • Start with a pilot project
  • Ensure management support and team support
  • Train enough
  • Use outside help (Scrum coach)
  • Set business-oriented goals
  • Measure to ensure success
  • Inform and communicate
  • Use simple tools



Recent Posts