Let’s start from the very beginning, which is – as Mary Poppns told us – a very good place to start.

All great things, no matter big or small, start with a vision. An idea for a super duper product that enables you to realise the next breakthrough in the industry. The vision of this product will lead to create what is called in agile/scrum jargon a product backlog. A product backlog is basically everything you need to do to make this vision becomes reality. To put it simply, it is your to-do list, ordered by priority. The most important item on top, the one that can wait longest on the bottom.

The person who owns this backlog is called  a product owner. He or she is the one and only to be responsible for this backlog. A product owner is a physical person and not an entity. So not a value chain, not a committee, not even a board or the president, an actual person like you and me. The product owner is not only responsible for the product vision and strategy, but – very important – for prioritization.

One single person can change the world, but most people need a team to realize the items on a product backlog. So, the product owner needs a squad (formerly known as a scrum team). A bunch of people who have fun making the product vision becoming reality, item by item. These items on the backlog are called user stories.

The squad realizes the user stories in a  fixed period of time called a sprint (typically 2 to 3 weeks). Every sprint starts with a sprint planning. During this planning session, the squad agrees with the PO what user stories they can pull in the sprint. Pay special attention to this as this is THE trick; the stories are pulled by the squad and not pushed by the PO. The PO only gives the priority in which the squad pulls items of the backlog.  At the end of each sprint, the squad holds a demo for the PO (who usually invites other stakeholders within the organization). During the demo, the squad demonstrates what they have delivered in the sprint.  The demo is followed by a retrospective. The retrospective allows the squad to look back to the sprint. Arguably the most important meeting of the whole sprint. In this session, a squad is able to close the feedback loop so the learning from last sprint can be addressed in the next sprint.

Now! That’s the whole essence of agile folks! Sounds simple? Yes! Sounds inspiring? Yes! Is a bit more complex in reality than on paper? Yes! But, the magic lies in the journey to apply the theory to fit your product, squad or organization. At our company, we applied the theory in a very specific way. You can read more about that in our post “Do it like Spotify: 4 take aways”

Do you want to keep reading about the scrum theory? Have a look at the scrum bible!

This work is licensed under a Creative Commons Attribution-NonCommercial 4.0 International License.