As a consultant, I noticed that different people have different perception and understanding of Scrum.
Here are some of the examples I have come across:
Project managers think that scrum as an agile project management framework for software delivery purposes.
Developers think Scrum is a framework that helps teams to work together.
Both answers are valid.
Let’s have a look at the definition of Scrum from Scrum Guide:
Scrum (n): A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.
It sounds complicated, isn’t it?
Well, don’t panic. I am here for help!
I will walk you through the background, characteristics, and processes in Scrum in layman terms.
Where does Scrum come from?
If you ask someone with a technical background, their answer would most likely be, “Oh, Scrum! Yeah! It was created by two amazing developers called Jeff Sutherland and Ken Schwaber! They came together and create Scrum as a formal process back in OOPSLA ’95….”
You know what? The origin idea of Scrum was actually coming from a rugby game!
Oh, does that mean the developers need to put their heads together while building software?
Well, not exactly. They do borrow the great team spirit from Scrum rugby game.
Let me show you how a scrum development team works in real life:
To start off, developers come together to plan, discuss the wishlist features (‘product backlog’), then deliver solution outcome in iterative cycles (‘sprint’).
Once an iterative cycle is reaching its end, the team will come together and discuss things they have learned within an iteration, and how things can be improved better in their next cycle (‘retrospective’).
This process will keep repeating itself until the final solution is delivered to the customer.
What are the characteristics of a Scrum team?
Now you should have a better understanding of what Scrum is, and how it works in the software development world.
Scrum team consists of three main roles:
- Product Owner – Responsible for maximizing the product value and work of the development team.
- Developers – Professionals who are doing real work to deliver solutions during the end of each release cycle.
- Scrum Master – Ensure a scrum team fully understood and adheres to Scrum theory, practices and rules.
What are the ceremonies in the Scrum team?
Did you just say ‘ceremonies’? Why do we need to do those?
That sounds like a bunch of activities that are wasting time!
Well, let’s take a look together what Scrum Guide says in below:
“Prescribed events are used in Scrum to create regularity and to minimise the need for meetings not defined in Scrum. All events are time-boxed events, such that every event has a maximum duration. ”
In simpler words, the ceremonies are designed to allow appropriate conversations taken place at an appropriate time with the appropriate group of people.
Instead of having ad-hoc interactions with the team on daily basis, it would be much better if the team can come up with an agreed time and place so that issues can be solved immediately during face-to-face discussions.
So, let’s go through the top 5 ceremonies (or ‘scrum events’) together now.
- Daily stand-up
- Sprint Planning
- Iteration Review
Daily Stand-up is a 15-minutes maximum timed box event for a development team. It usually happens at the beginning of the day.
The structure of a meeting can be conducted in different ways. In general, this is how a stand-up meeting would look like:
- The development team form a circle and facing one another.
- Each person will get the chance to talk about their situation, here are the classical questions to ask by the development team:
- What have you done yesterday?
- What are you going to do today?
- Are there any impediments or obstacles found at your work?
- (Optional) The development team will meet immediately for detailed discussions once the meeting is finished.
Sprint Planning is a meeting conducted before the next sprint begins. It is a team planning session that enables the team to decide and work together what needs to be delivered in the coming next sprint release.
Usually, this is a time-box event for a maximum of eight hours to one month sprint.
In general, the product owner will discuss the objective of the next sprint, and work items in the product backlog.
During the meeting, the development team will perform the following activities:
- Decide how much work they can commit into the sprint by pulling work from the product backlog into the next committed sprint;
- Work planned by the team will get decomposed into smaller units;
- Provide sizing estimations based on the work effort for each item;
At the end of the meeting, the development team and product owner will come to an agreement towards the work committed in the coming next sprint.
The development team will be self-organising to accomplish the sprint goal and deliver incremental deliverables.
This is a meeting that conducted near the end of a sprint. The idea of having a review is to inspect what has been done in the current sprint, and any changes to product backlog during the current sprint.
Here are the activities that will be taken place in the iteration review meeting:
- Product owner will present the items that is being “Done” and what is not being “Done” in the current sprint.
- Development team discusses what went well during the sprint, what are the obstacles that the team went into and how it is being resolved.
- The entire team will collaborate what to do next, which will benefit to the next sprint planning.
- Product owner will also provide feedback or review from end-customers so that development team will aware what to do next;
Sometimes, iteration review are also known as “product backlog grooming” since this meeting is about adjusting the product backlog based on the market response.
The retrospective meeting gives the development team an opportunity to come together and reflect themselves what they have done well, any improvements or suggestions for the next sprint.
This meeting normally has taken place before the next sprint begins.
Generally speaking, the team will come and discuss the following key items:
- How the sprint went in regards to people, relationships, process, and tools;
- What went well and potential improvements;
- Create a plan for implementing improvements together;
There are no strict rules on how the retrospective meeting should be conducted. It really up to the team to choose what kind of environment or format that suits them most.
In my past experience, I had my retrospective session while drinking beer with team members at the bar. I have also enjoyed a coffee at the coffee shop by writing sticky notes to exchange ideas.
I enjoyed both ways.
So… Do you have your retrospective ideas?
Have a chat with the team and see how it goes!
That’s it. You should have a better understand what Scrum is all about in agile software development.
Let’s recap what we have been discussed in this article:
- Scrum is a framework that helps teams to work collaboratively together to achieve a goal.
- The concept of Scrum was originally coming from Rugby games.
- There consists of 4 important elements in scrum ceremonies; sprint planning, daily stand-ups, sprint review, retrospective.
Please visit the official Scrum guide for more details about Scrum.
If you still have any questions or issues, simply leave me a message, I will try to get back to you as soon as possible.