A few Best Practices in running Agile Scrum

A Scrum Master is a guardian of Scrum principles and the one who ensures the overall effectiveness of the Scrum team. These are a collection of tips or best practices of practical nature that I am recording in my experience as a Scrum Master and also by observing other Scrum teams. The assumption is the readers are already aware of the Scrum practices and terminologies. If not, refer to the original Scrum guide here è The Scrum Guide. 

Hope the tips presented below will find some resonance in the experiences of folks involved in Scrum activities. Each of the points is hash tagged with a phrase on how it would help the Scrum effectiveness.

Daily Stand-up Meeting (DSM) :

The intention of DSM is to discuss the progress towards the goals of the Sprint.

• Daily Stand-up meetings should adhere to a strict timeline of not more than 15 minutes. In the DSM, the team members should just update the progress, blockers and plan for the next day.  #Efficiency, #FocusOnGoals
• If the risks/blockers need more discussion, it can be a separate one-one discussion with Scrum Master who can take necessary action towards resolution. #Efficiency There is always a tendency to get deviated in the DSM towards technical discussion. The Scrum master should check and prevent this. #FocusOnGoals
• Always have a defined placeholder meeting slot for technical discussions and clarification post DSM. Only the relevant team members need to attend that meeting. #Efficiency
• It is a good idea to jot down the points discussed in DSM in meeting notes and get it posted along with meeting invite in the calendar. Meeting tools like 'Teams' have the facility to record the meeting notes. #FocusOnGoals, #Transparency
• Daily attendance and punctuality in attending the DSM should be ensured. Scrum Master should track this and get valid reasons from each member who could not attend the meeting in time. #Accountability

Sprint Planning:

• Sprint Planning should be done before the start of the sprint and only stories for that sprint should be discussed in the meeting. #ClarityInExecution
• Going in to the Sprint Planning, the target list of stories should be populated in the tracking board e.g. Jira. All stories should have the 'Acceptance Criteria' defined prior to the meeting.  #ClarityInExecution
• Main focus for the Sprint planning can be discussions around "how" to complete the story.  Design approach, test cases needed, automation requirements etc can be discussed. Also the story points should be finalized by the team. #ClarityInExecution
• While discussing the story, have a target date for small milestones like code complete, review complete etc and record it in the story. Scrum Master can use this for tracking. #ClarityInExecution, #FocusOnGoals
• With the help of team, capture the points discussed in the meeting in the story itself so that it becomes a useful reference. #Transparency
• Towards the end of  Sprint planning, take an account of the stories planned and compare against the capacity (past velocity is the reference to be used). If the story points cross the capacity, the least priority stories should be moved to next sprint after discussion with product owner. #ClarityInExecution
• The story points taken up can be just below the capacity (plan conservatively) and the teams can be encouraged to pick up stories of next sprint if there is available capacity. #FocusOnGoals

Backlog grooming or Backlog Refinement:

Backlog grooming is where the team goes through the Product Backlog which is a list of future activities in the team’s board. It is probably the most under rated ceremony and it is not listed in the original Scrum guide. But this event when practiced systematically could be the game changer - the one which could be very useful to boost the overall effectiveness of the sprint planning.

• Backlog grooming should be done in regular cadence (ideally on a weekly basis) and it can be avoided in the week where Sprint planning is performed. #FocusOnGoals
• The meeting should majorly focus on stories in the upcoming sprint (not the current running sprint) and also to a lesser extent the stories planned in next 2 or 3 sprints. (Assume a rough product backlog with a sprint mapping is already available.) #FocusOnGoals
• The agenda of the backlog grooming should be to arrive at the detailed acceptance criteria of the stories. Any questions on the story can be discussed in the meeting. Jot down the points discussed in the story board. #Transparency, # ClarityInExecution
• The Scrum master can do ground work before going into the meeting by creating a question based agenda for each story and collecting all requirements, seeking necessary clarifications etc. #ClarityInExecution

Sprint Review:

The intent of the Sprint Review or demo meeting is to showcase the incremental work completed by the team to the customer and other stakeholders. The feedback from the Sprint review meeting gives direction to the team for its future course.

• A presentation should be prepared by Product Owner and Scrum Master which details the list of goals completed/not completed. #Transparency
• Presentation and demo should be easily understood by all, it should minimize technical jargons and it should use the language of end users of the software or product. #EffectiveFeedback
• Team members can record the demo and add it to the presentation. A recorded demo video is preferable to a live demo since it can avoid late set-up issues, network issues etc. #EffectiveFeedback
• Strict timing guidelines to be ensured for the Sprint review meeting. #Efficiency
• Scrum Master should work with Product Owner to ensure the relevant stakeholders are present for the Sprint review. #EffectiveFeedback

Sprint Retrospective:

In Sprint Retrospective, the team reflects on the previous sprint and discusses what is going well and what can be improved.

• Sprint retrospective meeting can follow the Sprint review meeting and it is ideally conducted in the last day of the sprint when the events in the sprint are fresh in memory of team members. #ContinuousImprovement
• There can be an online wiki page or virtual boards where the team members can log the individual points prior to the beginning of the meeting. There are different online tools available with templates for retrospective meetings. #ContinuousImprovement
• Give time in the beginning of the meeting for team members to enter their own points and then enter into an open discussion over the points. #TeamInteraction
• There are different retrospective themes and games which can be used by the Scrum Master to make the discussion interactive and fun. #TeamInteraction
• The list of action items or outcome of the meeting should be logged in a common area and it should be maintained in a wiki or a common location for team's reference. #ContinuousImprovement
• Scrum Master should be the guardian of the action items or improvements listed in the retrospective and should track those regularly. #ContinuousImprovement

Other general guidelines:

• The team members usually work on stories which are further part of a larger feature or epic. There should be a question based checklist for

1. Definition of Ready (DOR) : DOR checklist should be fulfilled before the teams accepts and plans the stories for the feature. DOR would have points like having technical requirements ready, behaviour defined in case of BDD model, validating assumptions as much as possible, arriving at design approach and getting a buy in from stakeholders such as Product Owner, Architects and if any other stakeholders. #ClarityInExecution
2. Definition of Done (DOD) : DOD checklist can be applied in different levels i.e. at story level, sprint level or feature level. DOD checklist should be fulfilled and evidence provided before the Product Owner can classify the story/feature as 'done' or completed. DOD checklist would have items like non-functional requirement adherence, passing of quality gates etc. DOD checklist should be standardized #Completeness

• There are usually tools like Jira where Story/Epic is maintained. Scrum Master should take care to link all associated artefacts of the story/epic in the board so that anyone one can navigate to the artefacts related to the story in a single click. The cross mapping ensures that the feature can be reviewed and understood easily and all related work item references are available. This becomes a living version of a traditional “Requirement Traceability Matrix” we are familiar with. The items to be linked are as follows and we can do more linking as applicable to projects:
• Technical Requirements - hyperlink to wiki or SharePoint or tool like Jama where requirement is written
• Design Doc - hyper link to wiki or SharePoint with the documentation
• Code - Reference to SCM tools like GitHub, Gitlab etc where the code changes and review comments are captured
• Build Pipeline – Reference to the Continuous Integration pipeline.
• Test Cases - Hyper link to any online tool where test cases are written or say SharePoint in case test cases are stored as documents
• Test Results - A dashboard with test results for easy viewing
• Automation - Link to the SCM where automation cases are captured
• Quality gates - Link to tools where actions such as Static code and Unit Tests are done
• Ensure important mails, decision logs which are relevant to the story is included in the board. #Transparency
• Make sure any activity done by the team member can referenced online through the tracking tool. #Transparency
• Maintain a Team Working Agreement: A Working Agreement list can be arrived at when a team is formed and it can be continuously refined as the team progresses through different Sprints. It is a democratic way of establishing rules. Working Agreement list can have general guidelines for the conduct and behaviour of the team members. For e.g., Agreement on Schedule and cadence of meetings, do's and don’ts of behaviours during development and testing, work flow of a story etc. #TeamInteraction, #Accountability