Evolution of  the Daily Scrum: From Status Meeting to Self-Organizing Developers Checking-In.


The Daily Scrum is the 15-minute huddle where the developers come together to check if they're on track to meet the Sprint goal. It's been around since the first version of Scrum, and while description of Daily Scrum and the questions asked during the meeting have changed over the years, its purpose has remained the same.

In the older description of Daily Scrum, it specifically started with saying “Each Scrum Team meets daily for a 15-minute status meeting called the Daily Scrum. The Daily Scrum is at the same time and same place throughout the Sprints. During the meeting, each Team member explains: (formatting of the word "status" and "explains" are mine)

1. What have you accomplished since the last meeting?
2. What are you going to do before the next meeting?
3. What obstacles are in your way?

And then in the later part of the section it stated “The Daily Scrum is not a status meeting.” It also stated “The intent is to optimize the probability that the Team will meet their Goal. This is a key inspect and adapt meeting in the Scrum”

As you can see the intent of the Daily Scrum from the earlier version of the definition of Scrum is to inspect if the team can meet the Sprint Goal or not.

​In 2011, the language changed a little bit, I think, towards the worse side. The change in the first line looked really good though. It stated “The Daily Scrum meeting is a 15-minute time-boxed event for the Development Team to synchronize activities and create a plan for the next 24 hours.” The status part is gone and it is not for the Scrum Team but for the Development Team. However, the questions remained the same. But the worse thing was what it said in the later part. It stated “Every day, the Development Team should be able to explain to the Product Owner and Scrum Master how it intends to work together as a self-organizing team to accomplish the goal and create the anticipated increment in the remainder of the Sprint.” Doesn’t that sound like a status meeting every day to report not only to the Product Owner but to the Scrum Master too?

In 2013, the description of Daily Scrum got much better. It still had those three questions. But the questions were tweaked to emphasize the team meeting the Sprint goal.

1. What did I do yesterday that helped the Development Team meet the Sprint Goal?
2. What will I do today to help the Development Team meet the Sprint Goal?
3. Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?

Also disappeared the statements that sounded like the developers are “explaining” to the Product Owner and Scrum Master on a daily basis.

In 2020, the three questions were dropped altogether.  This was a good move to make the framework in line with Scrum being a minimally sufficient framework. Removing this prescriptive language finally recognized that the three questions are not the only way to accomplish what we want to accomplish in Daily Scrum. Another welcome change is that, the guide do not say, as in the previous versions,  that “The Development Team or team members often meet immediately after the Daily Scrum for detailed discussions, or to adapt, or replan, the rest of the Sprint’s work”. It may sound like developers need to have scheduled meetings in order to collaborate.  In the latest version the statement is “The Daily Scrum is not the only time Developers are allowed to adjust their plan. They often meet throughout the day for more detailed discussions about adapting or re-planning the rest of the Sprint’s work.” This is line with the intent that the Developers are a team and they collaborate all the time.

The good thing is that the purpose of the Daily Scrum never changed. It has always been “ to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work.”

It is a good thing that the Scrum Guide itself continued to evolve - by inspecting and adapting and making changes. Unfortunately the world haven’t changed. I still meet a lot Scrum practitioners who think that the Scrum Master is to ask those three basic questions and that the Developers are to answer those so that Scrum master can make decisions - just like a status meeting with a team lead or a manager - every day, while standing up, possibly even before having a coffee. That sounds horrible. Shouldn’t we treat our team members as responsible adults? These people voluntarily signed up to work toward the spring goal, supposed to be self organizing.  Hum.... what did the Agile Manifesto say?

Dear ScrumMaster, Are you the one tracking (managing) the progress of your team's work on a daily basis? Should you be?


Here is the result of a survey conducted on LinkedIn (concluded on Jan 4, 2023). According to the 168 people who voted, it seems that most people believe that the Scrum Master is responsible for tracking the progress of the team's work.

The Scrum Guide does not clearly say who should be responsible for this task. But there are some indications.  Here are some quotes from The 2020 Scrum Guide ™¹

Under the Scrum Team Section
"Scrum Team is structured and empowered by the organization to manage their own work." It also says "The entire Scrum Team is accountable for creating a valuable, useful increment every sprint."

Under the Developers Section
The Developers are always accountable for:

• Creating a plan for the Sprint, the Sprint Backlog;
• Adapting their plan each day toward the Sprint Goal; and,
• Holding each other accountable as professionals.

Under the ScrumMaster Section
The Scrum Master serves the Scrum Team in several ways, including:

• Coaching the team members in self-management and cross-functionality

(This is the only part in the ScrumMaster section that says anything about planning or managing the plan.)
Under Daily Scrum Section
The Daily Scrum is not the only time Developers are allowed to adjust their plan. They often meet throughout the day for more detailed discussions about adapting or re-planning the rest of the Sprint’s work.

Given these responsibilities outlined in the Scrum Guide, it seems that we could go with either Scrum Team or Developers. There is no indication that the ScrumMaster or Product Owner be responsible for tracking the progress during the sprint.

Do you see this differently? Apparently 45% of you do. I would love to hear about your reasoning. Please comment or send me a message. 

My personal take is that, the developers should be primarily responsible for tracking the progress of their work. However, the ScrumMaster can certainly offer assistance and support in this task. The problem arises when the ScrumMaster is the only person concerned about whether the team will meet the Sprint goal, while the team members themselves do not seem to care. To me this means that ScrumMaster is not effective in coaching which the real responsibility. Instead of coaching the team, they are choosing to manage it themselves. Note that the Scrum Guide explicitly says that the ScrumMaster is responsible for coaching the developers in self management.

It’s like my parenting. I have tried so many ways to get my kids to clean up the mess that is left in the kitchen after they cook the simplest of meals. But they don’t, and I end up cleaning it up myself. Should I keep cleaning up after them? As a parent, I have some easy tools that I can use as in money, privileges, etc. But as a ScrumMaster, I don’t have any of that. So it is difficult to do. What have I seen? More often than not, it is an organizational problem. Based on the conditions that the Developers are working in, it is not always possible to care about the team’s progress at large even if they care. They are not empowered to do so or there is no incentive to do so. In some cases, individuals may be working on 5 other projects and they barely get time to do the work that they are an expert on; let alone looking at what the team at large needs to meet the Sprint goal. A ScrumMaster’s Job is do the investigation in the organization and try changing the conditions in said organization.

Have you encountered a situation where team members were not concerned about meeting the Sprint goal? If so, what did you do to address this issue?

I would love to hear your thoughts and experiences on this topic.


Back to all posts
​
References

1. https://scrumguides.org/scrum-guide.html

Here are some thoughts about Daily Scrum. These are notes I created while answering questions from a CSM class or from some of the coaching engagements. 

Some of the questions I hear about Daily Scrum are:

Who runs the Daily Scrum Meeting?  Who would make sure that developers stay on the topic? 
If the Scrum Master do not attend, who would make sure that Daily Scrum starts on time and ends on time? 

It is essential to understand that the Daily Scrum serves as a dedicated event for the Developers within the Scrum Team. The Developers have the autonomy to structure and employ techniques that best suit them, as long as their focus remains on making progress towards the Sprint Goal and devising a practical plan for the upcoming day's work. The Scrum Master's responsibility is ensuring that all Scrum events, including the Daily Scrum, are conducted in a positive and productive manner. If, during the meeting, someone speaks excessively or digresses from the intended topics, it does not solely fall upon the Scrum Master to intervene and redirect the discussion. It is crucial to recognize that the Scrum Master is not in charge of leading or managing the meeting. Instead, their role lies in providing the Developers with the necessary resources and knowledge to conduct the meeting effectively and help them create a working agreement within the team. This approach empowers the developers to evolve into a self-managed team. The Scrum Master could help by demonstrating what a successful Daily Scrum looks like or participate as an observer.

One of the key expectations is for the developers to function as a self-managing team. If the Scrum Master is unable to leave the team alone even for a 15-minute meeting, it indicates that the team might not yet be fully self-managing. In such a scenario, the Scrum Master's role shifts towards aiding the developers in their journey towards becoming a self-managing team.


What if the Manager of the team attend the Daily Scrum Meeting? 

According to the Scrum Guide, 
"The purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work."

"If the Product Owner or Scrum Master are actively working on items in the Sprint Backlog, they participate as Developers."

Could anyone else attend the Daily Scrum? Possibly. According to Scrum Guide, It is for the developers and they are the ones participating in in that meeting. Others could attend as a listener.



Here are several reasons why a Manager or other Stakeholders might choose to avoid attending in a Daily Scrum Meeting. 

1) Interference with self-organization: The Daily Scrum is for developers to inspect progress toward the Sprint Goal and possibly synchronize their work and plan their day. When a manager, particularly a hierarchical authority figure, joins the meeting, it can disrupt the team's ability to self-organize. The power dynamic may discourage open and transparent communication among team members.

2) Encouraging micromanagement: If managers attend the Daily Scrum, unintentionally, they might foster a culture of micromanagement. Team members may feel compelled to provide detailed progress updates to impress the manager, diverting their focus from collaborative problem-solving within the team. This can lead to reduced autonomy and motivation among team members.

3) Time inefficiency: The Daily Scrum is meant to be a short, time-boxed meeting for the development team to share quick updates. Involving managers who are not directly involved in day-to-day tasks can lengthen the meeting, decreasing its efficiency and hindering the team's progress. 

4) Trust and transparency concerns: The Daily Scrum provides a safe environment for team members to openly discuss progress, challenges, and obstacles. However, the presence of managers might discourage team members from expressing concerns or discussing issues openly. Avoiding manager attendance can foster an atmosphere of trust and transparency, enhancing problem-solving and collaboration within the team.

The Scrum Master should remain vigilant about these potential issues. It is also essential for the Scrum Master to understand the motivations behind a Manager's or stakeholders' desire to attend the Daily Scrum, which may include:

1) Lack of confidence in the Scrum Team or engaging in micromanagement.
2) Management not having alternative ways to stay informed about the team's progress.
3) Unawareness of the impact their presence may have on team members' ability to speak openly about issues.


Our Daily Scrum goes on for much longer than 15 minutes everyday and its mostly a waste of time. 

I) Lengthy Daily Scrum Meeting: 
If the daily Scrum extends for an excessive duration, it is crucial to investigate the underlying causes. Common reasons for lengthy meetings include developers trying to solve problems during the Scrum, lack of agreed-upon strategies to keep the meeting concise and focused, and treating the daily Scrum as a status meeting. Organizational issues, such as team members working on multiple efforts simultaneously also can contribute to developers attempting to solve all problems during the daily Scrum.



1) Making it as a Problem solving meeting: 
During the daily Scrum, while the development team is inspecting their  progress toward the Sprint Goal, they will identify impediments and roadblocks that is affecting the progress towards the Sprint goal. They do not necessarily discuss them or try to solve them during the daily Scrum unless they are resolved by a quick exchange between the team members. 

There are two reasons for not trying to solve problems in the daily Scrum: 

i) all of the developers do not need to be in a meeting to solve every problem. 
ii) There may be other parties who are not in the meeting to discuss these problems. The Daily Scrum should not be used to find solutions to problems (obstacles, impediments) raised. 

Instead, keep the meeting very short and have those problem-solving conversations afterwards with only those who are necessary. 



2)Format of the Daily Scrum: The most common format involves each team member sharing what they have done, their plans for the day, and any impediments. However, this format may resemble a status report and lead to longer meetings. Look for other techniques for conducting a daily scrum. 


How is Daily Scrum different from a typical status meeting? 
In the  Daily Scrum, the developers focus on progress they made towards the Sprint Goal, identify any impediments that are blocking progress, and the plan for the day ahead. The Daily Scrum is a brief, focused meeting that is intended to synchronize the team's activities and identify any impediments to achieving the Sprint Goal. It is not a status meeting reporting status to a supervisor or a manager, nor is it intended to be a problem-solving session. It is a time for the team to collaborate and plan their work. This is how Daily Scrum is different from other meetings. 

The Scrum Master plays a vital role in facilitating the Daily Scrum effectively. Their responsibilities include:
* Helping the team understand the purpose and significance of the Daily Scrum.
* For a new team, the Scrum Master facilitate the Daily Scrum and help the developers to learn to conduct the meeting effectively. The Scrum Master could also attend the meeting in order to observe and provide feedback for improvements. 
* Assisting the team in selecting suitable structures, formats, and techniques for conducting the meeting efficiently.


What are some Tips for effective/improving daily Scrum Meetings:

Signal for Excessive Talking: Establish a method for team members to indicate when someone has been speaking for too long. For example, use a prop like an Elmo doll to signal "That's enough, let's move on." The responsibility for concise discussions lies with the entire team.

Diversify the Approach: Instead of the traditional format of individual updates, try the "walk the board" technique. Select a prioritized item from the product backlog and have everyone share what they accomplished on it yesterday, plans for today, and any obstacles. Repeat the process for each item.

Maintain Suspense: Keep participants engaged by introducing an element of surprise. Let the current speaker nominate the next person to speak, rather than following a predetermined order.

Shared Ownership: Encourage team members, besides the Scrum Master, to facilitate standup meetings. Rotate the responsibility to promote a collaborative environment and diverse perspectives.

Display the Sprint Goal: Have a prominent visual reminder of the sprint goal during the meeting to prevent repetitive discussions of the standard questions.

Utilize the Sprint Confidence Chart: Adapt Dhaval Panchal's Sprint Confidence Chart. Team members privately reflect on the team's ability to achieve the sprint goal and vote on a confidence scale. Discuss significant differences and collaboratively identify daily activities to improve confidence. Record reasons for changes to foster continuous improvement.

​Back to all posts

Reference: 
Tips for Facilitating Scrum Events By Brad Swanson

Ten Tips for More Effective Daily Scrums By Mike Cohn 

Sprint Confidence Chart  by Dhaval Panchal

Scrum Guide - Section Daily Scrum

Backlog Refinement: An activity to improve Product Backlog items and Achieving Common Understanding of what to work on next
 
In this article, we will delve into the significance of Backlog Refinement, explore what occurs during this activity, and understand its ongoing nature within the Sprint. By uncovering the purpose and process of Backlog Refinement, teams can enhance their understanding, collaboration, and ultimately, better products in an effective manner.
 
 
The activity Backlog Refinement was referred to as “Backlog Grooming”. There are a few reasons behind this change. One reason is the negative connotation associated with the word "grooming" in cases of abuse. Typically, grooming refers to pruning plants or combing pets. The word "refinement" seems to be a better fit when considering what the Scrum does with the product backlog during this activity.
 
 
What happens during the Backlog Refinement activity?

1. Creating a common understanding of the Product Backlog items among the Scrum Team.
2. Breaking down and further defining Product Backlog items into smaller, more precise items.
3. Adding details, such as a description, order, and size, to Product Backlog items.
4. Ensuring that the Scrum Team understands the value (why) of each product backlog item.

Product Backlog Refinement is an ongoing activity that takes place during the Sprint. It can also occur during Sprint Planning to increase the team's understanding of items and boost their confidence in completing the selected items for the Sprint.

The Scrum Guide defines it as an activity (as opposed to a time-boxed event) that occurs as needed. For a team that is just starting out, it is advisable to set up an event, such as two 30-minute sessions, for Backlog Refinement. During these events, the Scrum Team comes together to review the next set of Product Backlog items likely to be picked up in the next Sprint. During this review, the Scrum Team identifies tasks that need to be completed in the upcoming days to refine those Product Backlog items. These tasks may or may not require the presence of every team member. Based on the need, the Scrum Team self-organizes to finish those tasks, ensuring that the Product Backlog items are better understood and broken down into smaller units before the beginning of the next Sprint.

It is important to note that the suggested duration of 30-minute events for Backlog Refinement is not set in stone, and as the team matures, they may find alternative ways to conduct this activity that better suit their needs. Additionally, it is not solely the responsibility of the Product Owner to perform Backlog Refinement. Product Owners without the input and insights of the developers typically lack the necessary skills to refine Product Backlog items.

One of the "rules" I suggest to new Scrum Teams is that "During Sprint Planning, it is not a good idea to consider any Product Backlog items that the developers haven't seen before." This suggests that the Scrum Team should have a common understanding of the Product Backlog items before considering them for a Sprint during the Sprint Planning meeting.

The Importance of Backlog Refinement for Scrum Team Effectiveness
Backlog Refinement is crucial for the effectiveness of the Scrum team. Without continual refinement of the Product Backlog, the team may encounter several issues. Large and vague Product Backlog items, as well as a lack of common understanding among team members, can lead to longer Sprint Planning meetings or even worse, situations where high-priority items cannot be selected for the current sprint due to unrecognized impediments.

By conducting Backlog refinement activities, these problems can be identified earlier, allowing the Scrum Team to address and remove impediments before the Sprint Planning meeting. This proactive approach improves the overall efficiency of the team and ensures that valuable items are not delayed or missed.

The Role of the ScrumMaster in Backlog Refinement
The ScrumMaster plays a crucial role in facilitating Backlog Refinement and ensuring the effectiveness of the Scrum Team. According to the Scrum Guide, the ScrumMaster is accountable for the team's effectiveness, making their involvement in this activity essential.
​
As a ScrumMaster, there are several ways to support the team in Backlog Refinement:

1. Help the Scrum Team recognize the importance and need for Backlog Refinement. Educate team members about the benefits of this activity in terms of improving collaboration, understanding, and overall productivity.
2. Assist the Scrum Team in developing efficient techniques for conducting Backlog refinement. This may involve exploring various approaches, such as story mapping, user story slicing, or other methods that align with the team's specific needs and preferences.
3. Facilitate better collaboration between the Product Owner, developers, and possibly user representatives during Backlog Refinement. Encourage open communication, active participation, and the sharing of insights and perspectives to ensure a shared understanding of the backlog items.

 
Reference in Scrum Guide(1)
 
Sprint section: “During the Sprint, The Product Backlog is refined as needed.” 
 
Product Backlog Section: “Product Backlog items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event. They usually acquire this degree of transparency after refining activities. Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a description, order, and size. Attributes often vary with the domain of work.”
 
Sprint Planning section: Part Two – what can be done in a sprint: “The Scrum Team may refine these items during this process, which increases understanding and confidence.”
 
​Back to all posts

References:
 1)The 2020 Scrum Guide by Ken Schwaber and Jeff Sutherland
 
Further Reading:
1) What Is Product Backlog Refinement? Add detail (and more) to backlog items
by Joel Bancroft-Connors

2) The Keys to Effective Product Backlog Refinement 5 Practical Tips to Keep Your Team Moving by Joel Bancroft-Connors

Today in our agile at home series, we're discussing using Scrum to manage remote learning and pandemic living with seasoned at-home agilist and Scrum Alliance® Certified ScrumMaster® and practitioner Aaron Vadakkan. His father, Certified Scrum Trainer® Manoj Vadakkan, started using Scrum at home with his sons when Aaron was about eight years old. 
“We continue to add more of Scrum to our daily routine as a family,” Aaron Vadakkan said. “So now my brother and I use Scrum to run our at-home business. I use Scrum at home and in club leadership at school and, of course, to organize my own work.”


Please read the complete article on the Scrum Alliance website. 

The role of a Scrum Master is often compared to that of a Development Team Leader or a Project Manager, but it differs significantly from both. While a project manager focuses on the overall project delivery, including scope, budget, schedule, and quality, the Scrum Master has a different focus. The Scrum Master's primary goal is to enable the Scrum team to work cohesively towards achieving their shared goal. Acting as a true leader, the Scrum Master empowers the team rather than managing them. Their role is to facilitate and guide the team's continuous improvement, helping them refine their working methods to reach their objectives. The Scrum Master holds responsibility for the team's effectiveness and is accountable for establishing and promoting Scrum principles and practices. In contrast, a Team Leader typically leads a team and ensures adherence to a specific process or approach. The Scrum Master, on the other hand, ensures that the Scrum Team is self-organizing and cross-functional, supporting team members in enhancing their practices to consistently deliver value.

A Scrum Master provides value in three key areas. The Deliverables of Scrum Master: 
1. Helping the Product Owner in Maximizing the value of the product: The Scrum Master supports the Product Owner in ordering the product backlog to ensure that the product delivers its intended value. This involves collaborating with stakeholders to understand their needs and priorities, and facilitating clear communication between the development team and the product's requirements and features.

2. Enhancing the Development Team's ability to deliver value: The Scrum Master fosters a collaborative and cohesive team environment by removing obstacles that impede the team's progress. They also facilitate continuous improvement within the Scrum team, enabling them to consistently deliver high-quality increments of the product. Instead of managing the team and taking on the job of coordination between team members, the Scrum Master help the developers to become a self managed team. 

3. Cultivating an environment for value delivery: The Scrum Master evaluates the organization's dynamics and identifies areas for improvement to create an environment where the Scrum Team can thrive and deliver value. They educate and coach the leadership and the organization as a whole, promoting a culture of continuous improvement and empowering the Scrum Team to reach its full potential.

Difference in Authority and Decision-Making:
* Scrum Master: The Scrum Master does not have direct authority over the team members. They foster self-organization and empower the team to make decisions collectively. They facilitate discussions and help the team find solutions to problems.
* Project Manager: The project manager typically has authority over the project team members and can make decisions on behalf of the project. They have a hierarchical relationship with the team members and are responsible for making critical decisions related to the project.


It is crucial for the ScrumMaster to refrain from giving specific instructions on how individual team members should carry out their work or which tasks they should prioritize. This is particularly important to keep in mind if the ScrumMaster has prior experience as a project manager, as they may be tempted to fall into this pitfall.


Further Reading:

1. Scrum Master stances  by  Dhaval Panchal
2. The Scrum Master Checklist by Michael James

​About Sprint 0/Sprint Zero/Iteration 0/Iteration Zero/Inception in Scrum/Agile Product Development 
Scrum Guide do not define Sprint 0. However, some organizations refer to a short time frame of getting ready for Sprint 1 as Sprint 0 or Inception. Sprint 1 will follow immediately after this period. During this period, The Scrum team along with other stakeholder will do just enough planning to get started. 

Sprint 0 should involve the entire Scrum team, including the Product Owner, Scrum Master, and Development Team and likely Stakeholders and other subject matter experts. The main objective of this time frame is to ensure that Scrum Team and everyone else are aligned on the the Vision and Goal of the product development. They work together to create a shared understanding of the Product by engaging in activities such as product visioning, identifying and prioritizing initial set of features, and creating an initial product backlog. They may also create a Product Road map. The Scrum Team also need to make sure that they are equipped with the necessary tools and knowledge to begin work on the first sprint. The Development Team will to ensure that the the items on the top of the product backlog are well understood and ready for Sprint Planning for Sprint 1.

This will be also a good time for Scrum team establish a Definition of Done, team norms, and communication protocols for the Scrum team and everyone else. The development team may consider setting up the development environment. In general, this is a time to do all those things that help you start your product development. 

One common pitfall of Sprint 0 or inception is to spend too much time on planning and not enough time on actually doing work. Another pitfall is to get bogged down in discussions around technical details or individual features, rather than focusing on the big picture and overall product vision. It's also important to avoid making assumptions or decisions in isolation, without consulting the rest of the team or stakeholders. To make time spent on Sprint 0 as effective time, make the time frame shorter and and even try to deliver a small features. Working on actual product development, however small it may be, help the team see the capability of the lack there of of the environment they have.

Further Reading: Avoiding Iteration Zero , Article written by George Dinwiddie

Howard Sublett interviewing Aaron Vadakkan

Listen to the Interview here
14-year-old Aaron Vadakkan uses Scrum at home and visualizes work with his family using a task board. Who's the Product Owner of this family Scrum team? Mom, of course. Meanwhile, Dad Manoj is co-presenter of "Saved by Scrum" with Aaron at Mile High Agile 2017.
The Agile Amped podcast series brings Agile news and events to life. Fueled by inspiring conversations, innovative ideas, and in-depth analysis of enterprise agility, Agile Amped provides on-the-go learning – anytime, anywhere.

Written by Aaron Vadakkan, CSM

​People often ask me how we started using Scrum at home. We started because we had a problem. My brother and I would always get in trouble because we would think we finished our homework, and go out to play.

​Then my mom would come out and ask us, “Did you do your homework?”
“Yes...”
“Are you really done with your homework?”
“Yes…”

​The problem would come up when my parents and I couldn’t agree on when the work was really considered “done” or not. For example, the definition of done for math is to show all the steps to get the answer. We would get in trouble because our definition of done was not the same as the parents’. Even though we thought we were done with our homework, we really weren't when my parents asked. Then, my dad introduced something he had used at work: The Definition Of Done. We used the definition of done as a checklist that both parents and kids agreed on. We had a general definition of done that applied to every activity that we needed to finish, and a Definition Of Done for each subject. From there, we realized that more of Scrum could be used to solve problems at home.

What is Scrum?¹

In general terms, Scrum is defined as a process framework. There are 3 roles in Scrum: The Product Owner, the Scrum Master and the Development Team. In our house, the Product Owner is the all-powerful, all-knowing, decision maker. She decides if something is important or not. And you guessed it right, our Product Owner is my mom!

I am the Scrum master. The Scrum Master the protector of Scrum, and they help everybody with how to practice Scrum. In our home, I am a member of the Development team as well as the Scrum Master.

The team does the work. So who’s left for the team? My brother, my dad, and I.

In Scrum, products are built incrementally in short timeboxes called Sprints. For us, the the Sprint is always one week long. It starts on Sunday and ends on Saturday. 

Scrum helps me to do the right things, do the things right, and get things done faster. This structure comes from a Scrum expert named Henrik Kniberg², and that's how this article is organized.

To get a complete description of Scrum, please visit the Scrum Guide.

Doing the Right Things

Scrum helps me to do the right things at home through our use of the Scrum board and the sprint planning meeting. Because our sprint starts on Sunday and ends on Saturday, we have the sprint planning meeting every Sunday afternoon. In this meeting, we identify things we need to do for the week. The Product Owner and the whole team must be present at the meeting. The Product Owner helps to identify the work and the priorities for the week, and we also get a list of assignments from our teachers.

Then we write them down on individual index cards. These index cards are kept on a board on the wall. This board is divided into 3 columns, named “To Do” “Doing” and “Done”. The cards can be moved throughout the columns during the sprint.

​The board helps me in several ways throughout the sprint. For example, sometimes, the Product Owner (mom) gets evil and makes us do more things than we actually can (sound familiar?). So, when my mom tells me to do an extra thing, I show her the board so she can see that we already have enough work for the week. But it can also work the other way. My brother and I can’t pretend to have too much work because the product owner can figure it out when she sees a nearly empty board. The Scrum board also helps me to remember things during the week. One Thursday, my dad was out of town, and he was going to come back the next day. I forgot to move things around on the board that week. I knew he would be mad if he saw the board like that, so I started moving a couple cards around. I finished my science homework, and I moved that card to the done column. I also finished the history homework, but I noticed that I still had to do the math homework… and that it was due the next day. So I had to quickly finish my math homework, and I moved that card also before I went to bed. So the next day, my dad was happy because he saw the board organized, and I was happy because if I hadn’t finished that math homework, I would have gotten a terrible grade in math that week.

​Doing the Things Right

Scrum also helps me to do the things right, with the Definition Of Done and the Acceptance Criteria. The Acceptance Criteria is specific to each card on the wall and is different for each card. For example, one of the cards on the wall was a health project where the outcome was to find out how unhealthy meals were at restaurants across the US. The things I needed to do on that project to get a good grade on it were to find the nutritional facts for the original recipe from a restaurant, make a new recipe, and contact the restaurant for more information.
So that’s what we write on the card, numbering each step 1, 2, 3 respectively.

Going Faster

How does Scrum help me to get things done faster?  To get things done faster at home, we use two things: The Daily Scrum meeting, and a special rule we use in our house. We have our Daily Scrum meeting next to the board every day in the evening. This is when we move cards around on the board for that day. In the meeting, we say what we did that day, what we will do the next day, and any impediments we had so that our parents can help us remove the impediments. By doing this every day, we get feedback on what work we did, and how much work we did that day. But we can get feedback even more frequently by using the 25 minute rule³. It works like this: when we come back from school, we take off our backpacks and eat some snacks. Then we start doing our homework. Along with starting the homework, we start a 25 minute timer. At the end of that 25 minutes, whether we're done with the work or not, we go to our parents and show them what we've finished.  We also get to take a few minutes break. So we get feedback on how well we worked and feedback on the work we did.

I talked a lot about feedback here, but how does this help me do things faster? Have you ever worked really hard on a big project non-stop, and at the end, when you show it to your boss, it turns out to be completely wrong? This problem, as we found out, can be fixed by getting frequent feedback. We use Scrum as a feedback loop, by getting feedback every week, every day, and even every 25 minutes. But getting things done faster doesn't mean that we are working any harder, rather, we get thing done faster by finding mistakes earlier and by getting feedback earlier.

Scrum has helped us solve a lot of problems we face at home and at school. We had the problem of not knowing what we should be doing, and it was fixed by using the Scrum board and the Sprint Planning Meeting. We also had the problem of not getting things done the right way, which was solved by the Definition of Done. Another problem we faced was the problem of not getting things done on time, which was fixed by the 25-minute rule and by getting feedback all the time.

What I have described here is not everything that is defined in Scrum. We do not practice all of Scrum when we use it at home, but we use most of it. One major difference that you will see is the lack of the shippable increment that is produced at the end of every sprint. We don’t have one single product we are working on in a sprint. Instead, there are several items we work on. However, like in Scrum, we bring the backlog items to a done state at the end of every sprint. Another part we haven’t described here is the retrospective meeting at the end of every sprint. We have begun to use this lately.

To conclude, we started using a single practice in Scrum to solve one problem. By implementing more aspects of Scrum into our home and school life, we found that we could fix not one, but many problems. Scrum helps us to get things done right, get the right things done, and get things done faster.
 
References:

1. Scrum Guide - http://www.scrumguides.org/
2. Product Owner in a Nutshell - https://www.youtube.com/watch?v=502ILHjX9EE
3. Pomodoro Technique - https://en.wikipedia.org/wiki/Pomodoro_Technique

 
About the Author:
 
Aaron Vadakkan, CSM, is a 13 year old who currently studies in 8th grade at Rocky Heights Middle School. He participated in 2 CSM classes. He is also an expert on “Scrum at Home”, which is the topic he wrote about. This topic has been presented by him twice at two global gatherings. He had an early start with exposure to scrum, even from age 8, and he has been practicing it at home for about 4 years. ​​​