SCRUM team members consist of 3 main roles: Product Owner, Scrum Master and The Team. Each role are closely inter-related. It is recommended for Scrum team members to be physically sitting together in the same location whenever possible.
Product Owner (PO) is the person who is ultimately responsible for the product, which could be a system, a small piece of software or even a component. He often understands the historical evolution of the product, well versed with the product current functionality, and define the vision of what the product will eventually be.
As the ideology of Scrum is to build a potentially shippable product at the end of every Sprint, PO is the person who ultimately decides whether or not to ship the product. Whatever decision PO made, he is answerable to the business in the larger scope. The decision made by Product Owner are often influenced by other Stakeholders (or Subject Matter Experts) and the business owner.
Ideally, PO is the person who is much closer to the customers (both internal customers or external customers). He understands the business challenges the customers are facing. He will communicate these business challenges to The Team by writing user stories so that The Team can build the necessary features.
A user story follows the following format:
As a <type of business user>,
I want <to perform certain task(s)>
so that I can <achieve some goals / benefits / values>
As a content editor
I want to be able to update my company website content without changing the source code
so that I can frequently let the visitors know the latest promotion
During Sprint Planning and Spring Grooming session, PO will provide as much details as possible to The Team related to the stories. At this point, PO would have completed writing each story and identify what is the priority for each story so that The Team can determine which story to pick first in Sprint Planning.
Some Product Owners who have a strong technical background might choose to write code together with The Team. However, he might not be able to commit on complicated stories or large number of stories due to his other obligations within the business. There are also some Product Owners who do not code but will participant in testing to work very closely with The Team.
In some organization structure, a business analyst might play a portion of Product Owner’s role due to the inaccessibility to Product Owner. Issues such as time zone difference or other business commitment might not allow the Product Owner to have high availability for The Team. Business analyst will step in to clarify the questions The Team has. Whenever business analyst is in doubt, he will clarify the matters with Product Owner.
Scrum Master is responsible to resolve any problem for the team members throughout a Sprint. Scrum Master is expected to understand different Scrum ceremonies better than the rest of the team members so that he can make the right call when conflicts arise. Scrum Master is the person who enforces the prescriptive guidelines in Scrum to ensure the Scrum team is able to reap the most values for adopting Scrum.
Having said that, Scrum Master does not have to be the most senior or most technically competent person in the Scrum team. In fact, Scrum Master might not even know technical at all. Scrum Master’s main responsibility is to clear out obstacles for The Team and enforce Scrum guidelines throughout the Sprint.
Now, let’s walk through Scrum Master’s specific responsibilities throughout the Sprint…
Prior to the Sprint Grooming, Scrum Master has to ensure Product Owner has completed writing every story and priority has been placed on every story.
Scrum Master has to call for a Sprint Grooming few days prior to Sprint Planning. A few days of buffer should be allocated before Sprint Planning because Sprint Grooming sometimes cannot be completed in a single session. During Sprint Grooming Scrum Master needs to ensure The Team fully understands the stories written by Product Owner and ensure The Team has all necessary resources to kick start the Sprint.
After Sprint Grooming, Scrum Master has to call for another session for The Team to estimate the story point for each story. Often in Scrum team there are 1 or 2 team members who are more senior or has deeper domain knowledge with the product. They will indirectly influence the story point estimation given by other team members as the less senior team members tend to look up to them. Scrum Master has to spot this early enough and encourage the junior team members to independently provide story point estimation and justify why a story should have a higher (or lower) story point. Scrum Master has the responsibility to ensure all team members are working in harmony rather than domination by senior team members.
During Sprint Planning, Scrum Master has to facilitate the Scrum team to finalize the stories to be committed in the coming Sprint.
In the perspective of Scrum, stories to be committed are always in accordance to priority defined by Product Owner. Among all prioritized stories, together with their story point, The Team will commit to the stories with highest priority and make a cut off at the point of hitting The Team capacity (velocity). Occasionally, 1 or 2 stories will be reshuffled for the best match of priority and story point to fit the team capacity within one Sprint. This has to be done with the acknowledgement of Product Owner.
Scrum Master’s responsibility during Sprint Planning is to ensure the above guidelines are followed. During Sprint Planning, Scrum Master has no say over whether to commit or not to commit certain story. The decision is entirely depend on the discussion between Product Owner and The Team. Again, Scrum Master role is to facilitate this process and to conduct a smooth planning session.
Daily Stand Up
Daily stand up is a quick 15 minutes catch up for The Team. Scrum Master has to ensure the following questions are answered by each team member:
- What did I accomplish yesterday?
- What will I do today?
- What impediment am I facing?
On Question 1: Under healthy progress, everyday every team member would have completed certain task to contribute to the completion of the stories. However, if Scrum Master notices a team member has not been able to accomplish anything in the last working day, it’s a sign that the team member is stuck at certain task. Scrum Master has the responsibility to find out what cause it and assist the team member to resolve it.
On Question 2: Under healthy progress, everyday every team member will pick a new task or continue working on the remaining task from yesterday. However, if Scrum Master notices a team member do not have the next task to move to, it is a sign that the team has committed less story than The Team velocity allows. If such situation persists, Scrum Master has to consider increasing team velocity in the next Sprint and take on more stories. In some occasions, a team member dare not to pick up certain task because it is too difficult / not enough domain knowledge / not sure what is the solution, Scrum Master has to identify the appropriate resource and make necessary arrangement to help the team member to proceed with the story.
On Question 3: Under most circumstances, team members will report there is no impediment. When a team member raises an impediment, Scrum Master should not dismiss the impediment lightly and should pay serious attention to resolve the impediment. It is Scrum Master’s responsibility to make use of his resourcefulness to make the necessary arrangement to get the impediment resolved as soon as possible to allow The Team to continue their progress.
Scrum Master should not dominate Daily Stand Up. A good Scrum Master will maintain his silence during Daily Stand Up but he is also quick to voice up when there are team members diverting from objective of Daily Stand Up.
Sprint Review is a session driven by The Team to demonstrate the deliverable (completed stories) to Product Owner. Scrum Master involvement during Sprint Review is often minimal.
Sprint Retrospective is the session to reflect what happened in the last Sprint. Scrum Master needs to get The Team to cover the following topics:
- What went well?
- What went wrong?
- What can be improved?
During the Sprint Retrospective, Scrum Master has to maintain a safe and harmonious environment for team members to speak up.
Scrum Master also has to ensure the team members understand the purpose of Sprint Retrospective is to provide continuous improvement for the coming Sprints rather than finding fault happened in the last Sprint. Therefore finger pointing should be avoided. Scrum Master has to ensure The Team carrying out the session to constructively identify the root cause of “what went wrong” and openly identifying “what can be improved” in the future Sprints.
Scrum Master has to take note of the items being discussed during Sprint Retrospective. Sometimes The Team will treat Sprint Retrospective as a good chat but forget about what has been agreed to do by the next Sprint. In this situation, Scrum Master has to step in to remind The Team that those are the items have been agreed upon and The Team should honor the agreement made during Sprint Retrospective.
In newly established Scrum team, The Team might be uncomfortable to speak up during Sprint Retrospective. A workaround for this scenario is for Scrum Master to request every team member taking turn to give at least 1 point for the 3 topics. This is also useful for matured Scrum team as The Team members often have many points to bring up. Having the team members to take turns to speak is an information flood control.
Of all the ceremonies in Scrum, a Scrum Master should NEVER dominate any session. In fact, Scrum Master is known as the servant leader. Scrum Master is the person to serve the team to ensure all team members are able to carry out their tasks efficiently.
In matured Scrum team, Scrum Master often play a passive role to monitor The Team is following Scrum guidelines. However in a newly established Scrum team (or team members who are less familiar with Scrum), Scrum Master has to play an active role to ensure The Team members are following the appropriate Scrum guidelines. If team members are diverting from Scrum guidelines, Scrum Master have to be quick to speak up to enforce Scrum guidelines and explain the purpose of the specific guidelines.
The Team is the main driver in a Sprint. The Team typically consists of Developer, Quality Assurance, Architect, Business Analyst and sometimes even Graphic Designer, Database Administrator to work together to deliver the potentially shippable product at the end of Sprint.
The Team is cross functional. The Team is able to step into different functional areas to ensure an user story is fully implemented. For example if The Team is handling Accounting module in a system. When a user story involving Sales module, The Team will be able to step into Sales module do the necessary work,.
In an ideal Scrum team, everyone in The Team is equal. There is no difference in title, role or seniority. Scrum does not recognize whether a member is a Developer, Quality Assurance, Architect, Business Analyst, or Designer. Everyone in The Team is equivalently qualified to pick up any story. Everyone in The Team should be able perform designing work, coding, testing, writing documentation, etc. The idea is to take on the full stack of tasks in a user story. However, this is often impractical in today’s many organizations.
In today’s many organizations, hiring process is role base. For example, the hiring manager might put up a job vacancy looking for “Developer with 1-3 years of ASP.NET & C#.NET experience” or “Quality Assurance with 1 years experience in building automation using Selenium”. Many development teams are not ready to embrace the ideal Scrum ideology where every member can do full stack of tasks in the story.
With that, a less drastic and practical approach to embrace Scrum value of “everyone is equal” is by actively encouraging team members to step into different roles within The Team.
The idea is to allow team members to step into different roles and doing different tasks they are not “officially” responsible for. For example, an Architect is encouraged to actively code and implement user stories; a Developer is encouraged to help out in testing; a Business Analyst is encouraged to help out in testing, a Quality Assurance is encouraged to help out in documentation, etc.
When team members step into different roles within team, team members learn to see the development task from a different perspective and be able to communicate from the perspective of different roles. Not only this will keep team members’ job interesting, but also enhance team members’ career growth by having wider scope of development experience.
Let’s walk through the main responsibility for The Team during different phases:
Sprint Grooming – All members in the team should get good comprehension with every story. All questions related to user story implementation should be clarified by team members. Junior members tend to rely on the senior members to “figure out” the story. This should be avoided. Again, every team member is equal in a Scrum team. Every team member should understand every story the best they could because any team member is expected to be capable to pick up the story later to implement it.
Estimation – All team member has the equal right to decide what story point the story should have. Junior members tend to look up to senior members and follow their story point estimation. This should be avoided. Every team member is encouraged to provide independent estimation. When estimation is significant varied, the team member is encouraged to provide justification why the given story point is significant higher or lower. Junior team member might not necessary know less on specific scope of the story. The purpose of such explanation is to allow the rest of the team members to identify aspects they might have overlooked or unaware.
Sprint Planning – Assuming Sprint Grooming is fruitfully conducted and estimation is agreed earlier, Sprint Planning will be a smooth process for The Team to formally commit to a set of user story up to The Team capacity. Product Owner might shuffle around a few stories, The Team will have to provide their insight whether such arrangement is feasible.
Daily Stand Up – Once the Sprint started, team members will pick up story and implement the full stack story. On daily basis, team members will gather at the same time to report the following questions to the rest of the team:
- What did I accomplish yesterday?
- What will I do today?
- What impediment am I facing?
The purpose of Daily Stand Up is for team members to be aware of what each other are working on to avoid redundant effort. It is also a platform for The Team to expose any problem early enough for the whole Scrum Team to act on.
Sprint Review – is the time for team members to proudly demonstrate what they have accomplished in the Sprint. As the full stack of tasks for a particular story is implemented by 1 or 2 team members, the respective team members naturally have strong ownership on the story. It is best for the respective team member(s) to demonstrate the completed story to Product Owner during Sprint Review. Product Owner will provide feedback whether he is satisfied with the deliverable. Team members will listen to PO feedback and take necessary actions base on the feedback.
Sprint Retrospective – is the time for team members to reflect back what happened throughout last Sprint by answering:
- What went well?
- What went wrong?
- What can be improved?
Team members are encouraged to acknowledge other team members who has done well. This is not only subjected for the senior members to recognize the junior members effort. Junior members are also encouraged to identify other team members who have done a good job in the last Sprint.
When addressing what went wrong and what can be improved, team members are encouraged to be courageous to speak up yet be compassionate while speaking. A Scrum team is very much like a working “family” team. If there are problems need to be addressed in a team, it is best for the issues to be resolved as soon as possible in humane manner. Improvement such as processes, resources availability, better approach to deal with a issues are to be discussed during Sprint Retrospective.
This concludes the series of Scrum article. If you find the information useful, please share it. If you would like to discuss specific aspect of Scrum or have certain scenario would seek my advice, please leave me a comment or go to Contact Daniel form to send me a personal email.