In Scrum Development – Part 1, we discussed the fundamental of Agile development which covers 4 Agile Manifesto. Lacking understand of Agile Manifesto often lead team members to practice Scrum ceremonies for the sake of practicing – without realizing the purpose of each ceremony. If your intention is to run a successful Scrum team, I highly recommend you to grasp a solid understanding of the 4 Agile Manifesto before moving to the prescriptive ceremonies in Scrum.
Guidelines for Scrum Team
- Each Sprint typically runs for 2 weeks. The duration of a Sprint could be from 1 week to 4 weeks. However through experience, 1-week Sprint is too short that leads to rushing and too much overhead while 3-week or 4-week Sprint is too long that leads to unnecessary idle time and big-bang implementation and deployment which makes Sprint harder to manage. A 2-week Sprint is ideal in most project.
- An ideal size of a Scrum team consists of 1 Product Owner, 1 Scrum Master and 7 (with +/- 2) team members. A team with less than 5 team members is too small to build anything significant; while a team of more than 9 team members are little too large to manage. Depending on the scope of the project and resource availability in organization, 7 (+/- 2) team members is not a stone-carved law to follow but rather a best-practice guideline.
Sprint Grooming is a pre-sprint activity that takes place before sprint starts. During grooming session, team members would clarify the stories written by Product Owner. Completed stories (or at least the majority part of the story) must have been completed by Product Owner, so that team members could clarify issues regarding implementation (either functional or technical or both).
The following is the format of how a story should be written:
As a <type of business user>,
I want <to perform certain task(s)>
so that I can <achieve some goals / benefits / values>
During this stage, the team might need some time to carry out research to evaluate whether a story could be implemented and how much effort is required. On the other hand, Product Owner could encounter edge scenario asked by the team. Product Owner potentially need time to check with the respective stakeholders to finalize a decision. Although such situation is expected, a matured Scrum team and a seasoned Product Owner who understand business use cases well would keep such get-back-to-you-later discussion to minimal. Sprint grooming could take place for multiple sessions depending on how productive each session went.
Before Sprint Planning begins, team members would have all questions in stories answered and have finalized the story point for each story. Note that estimation should NOT be hour estimation. Estimation done in hours defeat the purpose of Scrum. Scrum estimation is to be done using relative size. Tools such as Poker card or T-shirt size are good options to measure the complexity of story. In order for relative estimation to work, team members must have a common ground on the complexity of base point of 1. For example, if 1 point is equivalent to X amount of complexity, a story that carry 5 points means 5 times more complex than the 1 point story. 5 times more complex does not necessary means it takes 5 times the effort to complete it. Again, the base point of 1 is vitally important to form the base understanding among team members. Without defining base point of 1, story point estimation would be meaningless.
During Sprint Planning, team members and Product Owner would finalize which story to be committed in the Sprint. Depending on the team velocity, total story point and priority of each story, Product Owner (with the feedback and influence of team members) would select the best combination of stories to be committed for the Sprint. Note that requirement clarification should be kept minimum during Sprint Planning as requirement clarification should have been completed during earlier Sprint Grooming session. The more requirements was clarified during Sprint Planning session, the less accurate the story point estimation represents.
Daily Stand Up Meeting
The purpose of daily stand up provides a platform for the team to expose potential problem early enough. During stand up meeting, 3 questions would be covered by each team member:
- What did I accomplish yesterday?
- What will I do today?
- What impediment / obstacle am I facing?
Question #1 is designed to ensure team member accomplished what he has committed to the rest of the team on the previous working day. Having the team member to proactively report his progress is a much more motivating approach compared to having a traditional project manager to ask “Have you completed Task X?”. It gives a sense of pride to the team member for accomplishing tasks and announcing them to the rest of the team.
Question #2 is designed to ensure team members are moving forward everyday throughout the Sprint. By having team members to commit to story on their own will, they would naturally have a higher sense of ownership and accountability for the stories they have committed.
If everyone is moving forward together, then success takes care of itself. -Henry Ford
The purpose of Question #1 and #2 are to ensure the team members are being productive everyday. When Scrum Master notices a team member has been stuck with the same task for longer than expected, it is a potential signal that the team member is experiencing difficulty. A seasoned Scrum Master would spot this early to resolve it quickly rather than getting unpleasant surprises at the end of the Sprint.
Question #3 is designed for team members to raise any obstacle they are facing. Often in a less matured Scrum team, all members would say “No impediment” during stand up meeting. A “No impediment” response does not necessary mean no problem. The team members are sometimes too shy to raise the obstacle during stand up meeting. This is a common observation for newly established Scrum team or new team member joined the team. In more matured Scrum team, team member would proactively raise obstacles during stand up and quickly resolve them.
An important note to remember during daily stand up is the “people” element. The focus should be placed on the team members to allow them to keep moving forward. A poorly run Scrum team shift the focus away from the team members to the status of tasks completion. This is due to some traditional project managers are not familiar with Scrum approach and feel more comfortable getting tasks status update. Through experience, focusing too much on tasks status update is a less efficient approach to manage Scrum team which often lead to 11th hour additional tasks because team members are “trained” to close a task rather than to complete a task. A more efficient approach is to focus on the team members’ ability to progress. Highly motivated team members would go all the way to help each other and do whatever it takes to complete all committed stories. At times, the team would even resolve obstacles before the Scrum Master is aware of them.
One of the most important role of Scrum Master is to create a supportive and safe environment for team members to speak up during daily stand up. Blaming particular team member or finger pointing must be avoided at all cost. However, that does not mean being lenient while dealing with challenges. The guideline is be critical on issues, be kind to people. Scrum Master should not dominate daily stand up meeting discussion. Scrum Master is playing the role of a “referee” to ensure the team members are getting the most value out of Scrum ceremonies. A Scrum Master in a matured Scrum team would merely serve as an observer and only speak up when help needed. A Scrum Master is also known as a servant leader. (More on Scrum Master’s role will be covered in Part 3 of the Scrum article series.)
Daily stand up is designed to run for 15 minutes or less – that’s why team members should physically stand up during the meeting. Sitting comfortably encourages team member to drag the meeting to longer than require. The act of standing up to conduct the meeting encourages team members to finish the meeting in 15 minutes or less (because it would be too painful to stand for too long).
Often, team members are tempted to discuss specific issue with another team member during stand up, which potentially be a waste of other team members’ time. Story specific discussion should be taken offline among the team members working on the story.
Although all team members standing up together physically might not be feasible involving remote team members, the fundamental objectives of daily stand up should not be diverted due to physical limitation.
Sprint review is the activity where the whole Scrum team demonstrates the completed stories to Product Owner. The team member who implemented of the stories is responsible to demonstrate the respective stories. Stakeholders from various departments would often join the review / demo session to understand the newly implemented stories.
The objective of Sprint Review is to provide product incremental changes to Product Owner and stakeholders, so that there will be no big-bang surprises. Imagine in a non-Scrum approach of development (say Waterfall), a team works on a module for 6 months and when they finally demonstrate the working module to the customers, the customers feedback “No, this is not what we want”. 6 months of development effort would go down to drain. Sprint Review serves as a milestone checkpoint to allow Product Owner and stakeholders to acknowledge the team is moving towards the right direction and they are happy with each milestones.
At the end of Sprint Review, Product Owner would provide feedback whether he is happy with the work and decide whether to ship out the product. Remember, in Scrum, at the end of every Sprint there must be a potentially shippable product. However, whether to ship the product or otherwise is entirely up the Product Owner.
Sprint Retrospective is the meeting where team members reflect back how well did the Sprint go and discuss if there is any room for improvement.
The retrospective includes 3 main questions for discussion:
- What went well?
- What went wrong?
- What can be improved?
Question #1 is designed to acknowledge the good doing happened during the Sprint. A team member who has gone the extra miles to help another team member should be acknowledged. An unforeseen obstacle during the Sprint has been proactively resolved by the team should be acknowledged. The idea is to acknowledge the team members who has done an outstanding job during the Sprint and encourage the team to continue the good teamwork.
Question #2 is designed to identify the areas for improvement. No problems should ever be swiped under the carpet. If there was an unpleasant incident due to process inefficiency should be highlighted. If there was an external interruption that caused the reduction in team productivity should be highlighted. The idea is to identify what are the pain points for the Scrum team, so that the team could optimize and increase the team velocity.
Question #3 is a continuation of Question #2. The issues identified earlier should be discussed and identify a solution by the team, so that the same problem would not happen in the coming Sprint. The idea of Question #2 and #3 are to strike for continuous improvement in the Scrum team. No matter how good a Scrum team is, there is always room for improvement. This concept also known as Kaizen (改善) which means improvement for the better.
Often in less matured Scrum team, team members are less likely to speak up what’s in their mind. Scrum Master could consider enforcing every team member to take turn answering all three questions above to get team members be more comfortable speaking during Sprint Retrospective. Even if the team member says something like “Same with the other guy” is a good start. In more matured Scrum teams, team members would proactively prepared a list of topics (along the line of 3 questions) to bring into Sprint Retrospective for discussion.
One Last Thought…
While Scrum ceremonies are the activities that make a Scrum team, team that practices Scrum ceremonies for the sake of practicing gains little value for running project in Scrum. It is important to remember the underlying objective of each ceremony to gain the most out of these carefully designed ceremonies. In Part 3, we will discuss more about The Tools and The Team (people) in Scrum.