Warning: preg_replace(): Compilation failed: invalid range in character class at offset 4 in /home/duncanha/public_html/blog/wp-content/plugins/crayon-syntax-highlighter/crayon_langs.class.php on line 340
scrum events – Duncan Halley's Blog Skip to main content

The Agile Manifesto

In February 2001, 17 individuals came together and wrote the Agile Manifesto, which says:
We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:

  • Individuals and interactions over Processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

© 2001, the Agile Manifesto authors. This declaration may be freely copied in any form, but only in its entirety through this notice.


The Agile Manifesto in detail

But what does all of the above mean when it comes to carrying out Agile methodologies in practice? Let’s look at each point in turn – as our team use Scrum, that’s the framework that I will use for reference.


Individuals and Interactions over processes and tools

In Scrum, the team is all. They must work together to plan Sprints, estimate, do the work – the list goes on. There should be effective interaction both within the team and with individuals outside it so that the Scrum team can establish a good quality Sprint Goal and work towards it.
Regardless of who the interactions are between, the most important aspect is to ensure free flowing communication. This can be achieved by:

  • Creating a blame free culture
  • Ensuring individuals are able to speak up (see planning poker and silent writing)


Working software over comprehensive documentation

The aim of each Sprint is to produce a working increment of potentially shippable product. Agile values an increment of working software over large amounts of documentation which likely provide no business value.

Comprehensively planning and documenting user requirements don’t give you anything of business value. It’s only when an increment is developed, that we get a return on investment.

However, we still need to create documentation as long as it doesn’t interfere with the development of the increment. I would also say that user guides, for example, can create business value – without it, users may be unwilling to use your product.


Customer collaboration over contract negotiation

Only by collaborating with your customer can you understand what they want. You might think you know what they want, and you can even suggest this to them. But ultimately, you need to build a product that has the features they require.

This is even more important in Agile, where we focus on adding features that will add business value. The Product Owner (acting as a proxy for the customer) doesn’t want extraneous features adding, just because the development team thought it’d be cool. I’ve seen examples of this and it’s a perfect way to really annoy your customer.


I would say that once you start to have an idea of requirements, this can be put into a contract. But the contract needs to allow for changing requirements. If we were doing Waterfall, the contract would be set in stone, alongside the requirements, at the start of the project.
But we’re doing Agile, we expect the requirements to change, so that contract needs to account for this.

The beauty of Agile is that the requirements will naturally emerge as the project progresses. The customer sees the increment during the Sprint Review and this allows them to feed back on what they like and what isn’t as they expected. This feedback is then used to adapt the increment in the next Sprint.

Underpinning all this is communication. If the developers aren’t sure what the customer wants, then ask the customer.  If you ask them straight away, you can prevent minor issues from growing into large problems.


Responding to change over following a plan

In the Waterfall model, we create detailed plans right at the start of the project. But this is the time when we’re least equipped to plan – we don’t know enough about what’s required from the product. Once you realise that change is required, it’s often too late.


Agile accepts that requirements will change and emerge as the project progresses. We do plan in Scrum, but it’s a continuous process. By utilising relatively short timescales (the Sprint) we are offered more frequent opportunities to inspect the product and adapt it.

If a plan isn’t working, then why stick to it? Look at why it isn’t working (inspect) and change it (adapt) based on past experience.

We also ensure that we don’t plan too far ahead. If we plan too far in advance, by the time comes to implement the plan, the product and environment are likely to have changed, rendering the plan useless.



When working on a Scrum project, it’s important to try and keep the Agile Manifesto at the back of your mind. Think to yourself:

  • Are my interactions with others adding value or are they causing impediments?
  • Do we need this amount of documentation or can we take advantage of “Simplicity – the art of maximising the amount of work not done”
  • Are we effectively collaborating with the customer?
  • Is our plan working, and if not, why not? Are we able to inspect and adapt it? Are we planning too far ahead?


Read the original Agile Manifesto, and get translations, here.

Scrum Events – The Sprint Review

The Sprint Review meeting takes place at the end of the Sprint. It allows the product increment to be inspected by the stakeholders and for the Product Backlog to be adapted by adding new items or rearranging existing ones.

The Sprint Review meeting is timeboxed to 4 hours, for a 1 month Sprint.

The meeting is attended by the whole Scrum Team, plus any stakeholders who have been invited by the Product Owner. First, the Product Owner explains which Product Backlog Items (PBIs) have been Done and which have not been Done.

Following this, the Development Team discusses what went well, any problems they had and how these problems were overcome.

Then the Development Team demonstrates the work that has been Done and answers questions. This is intended to be an informal demonstration, typically without the use of PowerPoint presentations. The presentation allows stakeholders to ask questions and give feedback on the increment.

sprint review meeting

During the Sprint Review, the Scrum Team should be able to demonstrate that the Sprint Goal has been met.

Following the demonstration, the Product Owner discusses the Product Backlog and may project likely completion dates based on the work completed so far.

The group takes a look at the overall timeline, budget and marketplace for the product, to give context for the next release.


The Scrum Guide also lists the following activities as part of the Sprint Review. In reality they are often moved to a separate event – Backlog Refinement.

  • The group collaborates on what to do next i.e. is the Product Backlog correctly prioritised or is it missing items?
  • A review of how changes to the marketplace have affected the work that needs to be completed next.

Scrum Events – The Daily Scrum

The Daily Scrum is time-boxed to 15 minutes and allows the Development Team to synchronise their activities and create a plan for the next 24 hours.

The Daily Scrum should be held at the same time and place every day – the consistency reduces complexity.

Only the Development Team participates in the Daily Scrum. That is, only they talk. Other people are allowed to attend the meeting.


Daily Scrum


Should the Product Owner attend the Daily Scrum?

There are arguments both for and against the PO attending the meeting.


  • It increases Transparency, so the PO can keep up to date with the progress of the increment.
  • The Development Team can question the PO about Product Backlog Items in order to clarify them.


  • The invisible gun effect – even if the Product Owner doesn’t try to influence the meeting, the presence of someone with power and status can negatively affect the self-organisation of the team. Team members may be less likely to say what they really think.


The Three Questions

At the Daily Scrum, the Development Team members each answer three questions:

  1. What did I do yesterday?
  2. What will I do today?
  3. What impediments do I face?


The Daily Scrum allows the Development Team to Inspect their progress towards the Sprint Goal. The team are only reporting to themselves, not a Boss, and it’s a great way to monitor this. It also highlights areas where a team member may be struggling and enables the team to Adapt to this.

The Scrum board can be updated before or during the Daily Scrum. It is interesting how an action as simple as moving a card on a board, can motivate the team and provide a real feeling of ownership of the work and the resulting Increment.

The team can additionally meet after the conclusion of the Daily Scrum,  in order to discuss any issues or plan in more detail.