At CivicActions the PM and the ScrumMaster are the same (although it is conceivable that we would ask a non-PM to be a ScrumMaster).
There are aspects of the ScrumMaster role that relieve some traditional PM responsibilities. For example, on a scrum team, the team should be self-managing. Less impetus is put on the PM to manage team members, however we still ask the PM to recognize risk, velocity, and big picture management. The PM also manages budgets, plans for resourcing, and handles top level communications. The PM however is not a gatekeeper and the scrum team has access to all client communications, documents and a direct relationship with the PO.
- Scrum notes (taking & sending)
- Timebox monitoring (15 minute call)
- Sticking to the scrum process (avoid discussions mid-checkin)
- Keeping the team on task
- Getting everyone on the call, pinging them and making sure people are prompt
- For team members that are consistently late or disruptive - The PM should remind them privately of the processes and expectations
- Keeping the team focused and on topic (this may mean the PM may have to interrupt them if they start going down the path of discussion instead of a check-in)
- Being ready to jump in in case people forget who hasn't gone (although letting them sweat for a second is good too in them realizing they should pay attention better)
- Helping folks remember the structure of the call (if the PM senses they haven't grasped it quite yet). This should be done quickly - 20 seconds max. "As a reminder please state your balance score, what you worked on yesterday, what you're doing today and if you have any blockers or after meetings to request."
- Then at the end of the call, the PM gives their checkin if they hadn't already and rolls right into announcing the blockers, actions, or additional meetings that need to happen as a result of the scrum call
- PM sends out the scrum notes to the client mailing list (using the scrum note template.)
- The sprint review & demo will provide an informal once-per-sprint time slot for the team (UX, Design, Dev) to show their work as it stands at the end of sprint.
- Some of the work demo'd may not be completed, but we will show what we have so far. This is a live demonstration of work (yes, still in progress). It is not a report.
- We will invite the PO to this meeting, as well. The PO will help the team decide which work is done and what needs to be returned to the backlog (perhaps with a new ticket).
- The purpose of the demo is to help us stay transparent on our progress, keep us honest to our work commitments, show the rest of the team the work we did, and provide a space for the PO to approve or request changes to the work on the spot.
- During a sprint demo, the PM's major role is as facilitator.
- Always give your team preparation time for the demo - they need to remember the tickets they worked on and refresh themselves on what to present.
- The PM should always start the meeting; explaining the agenda, its purpose, the timebox, and any processes the team should follow.
- The PM should be taking notes as team members demos their work. Notes should include include things like questions and answers on a task demoed, work that is incomplete or not functioning, and any outstanding work needed to complete a task.
- The PM should document these notes somewhere the team can reference them. Suggestion: add the notes for each task to the ticket itself and call attention to the responsible team member.
- The PM could also consider adding a comment to a ticket that was demoed but had no questions or changes. Suggestion: indicate the date the ticket was demoed and that it was approved with no revisions necessary.
- The PM should help the team members understand the changes that need to happen based on the feedback from the demo.
- The PO should not be called on to demo anything, but they should be called on to approve or for any comments for each task demoed.
- The PM should keep track of the timeboxes.
- The PM should close the demo/review meeting by letting the team know where they can find the notes for their tasks demo'd and what the next steps are for the team and in the sprint.
- Timebox the demo to 1.5-2 hours, and divide that time by the number of team members. This is generally the amount of time each person can take to present their work. Remember to leave time for Q&A and the PM intro.
- The PM should state to the team how much time they each have to present (this can be stated the day before as well as at the beginning of the demo).
- The PM should ask for a volunteer to start and then ask that first volunteer to verbally pick the next person to demo.
- The PM can suggest the order of engineers go first, then UX, then design.
- Questions should be asked after each person demos their work so topics are fresh.
- Consider recording the meeting/demo.
- Scheduling the retrospective
- Facilitating the retrospective
- Keeping to the timeboxes
- Ensuring all voices are heard & participate
- Documenting the outcomes and adding the outcomes of the retrospective to the #retrospecting Slack channel
- Helping the team keep & meet their commitments
- The retrospective meeting happens at the end of every sprint. We will discuss what went well, what could be improved, what we learned, what perplexed us, acknowledge who we're appreciative for, etc.
- How we structure the retrospectives may vary from sprint to sprint.
- We should come to a consensus on actions items that we will commit to trying in the next sprint - in order to help us improve.
- The PO may or may not be included in the retrospective, but some of our major take-aways should be shared with them if they do not attend.
- When a project launches/closes, holding a final overall retrospective should be considered.
- Have a retrospective EVERY sprint. Even if you keep it short, have the call.
- Keep track of what the team wants to do differently next time and with the help of the team implement these changes.
- Join the #retrospecting Slack channel:
- Check out this retrospective template: TEMPLATE: Sprint Retrospective (Basic)
- Review this retrospective template: TEMPLATE: Sprint Retrospective(Grouping Issues)
This meeting helps the team prepare tasks for the next Sprint Planning Meeting. Ideally the whole team partakes, but the Technical Lead, Product Owner, and Project Manager must attend for the meeting to be well balanced and effective.
- Collaborate with the PO prior to the meeting and establish what the meeting should accomplish
- At the beginning of the meeting, state the goal and timebox (1-2 hours)
- Share your screen, while looking at the backlog together
- Guide the team in doing the following during a backlog grooming session:
- Write user stories using the template "As a [user type] I want to [achieve some goal] so that [some reason]."
- Break down user stories that are too big (epics)
- Improve user stories that are poorly written
- Estimate backlog items with story points
- Prioritize new tasks into the best spot in the backlog
- Add acceptance criteria
- Look deeper into the backlog to do longer-range technical planning
- Ensure the PO and team have identified the top 10-20 highest priority tasks and they are listed in the backlog
Here is a helpful video example: https://youtu.be/b_WeHcZcx1w
Occasionally the development team needs to meet to plan or process things together. Some examples of these types of meetings may be:
- Setting working agreements
- Changing workflows for code review, merge requests, QA, etc
- Direction to take with decisions from a retrospective
- Adjusting how the team works together
- Discussing a failing test that team needs to figure out
- Deciding on automated testing processes
- Assessing user testing feedback
- Demos and their outcomes
During these types of meetings the PM should do the following:
- Schedule the meeting & send out the invite
- Timebox the meeting appropriately and ensure the team sticks to the timebox
- Make sure the appropriate team members are in the meeting (and marking others as optional if not critical)
- Summarize the purpose and goal of the meeting (both on the invite and state it at the start of the meeting)
- Ensure the team stays on topic to meet the goal and get the outcome needed
- Document the meeting notes and share with the appropriate mailing list
- Clearly outline next steps and action items for the team
- Ensure there is ownership for each action item & the team knows the due dates if applicable
- Create any tickets or documents necessary (even if it is just a stub ticket or document template)
- Follow up on the action items the team agreed to & help them stay accountable to their commitments
- Note taking for every meeting
- Sending notes and deliverables to PO
- Scheduling meetings
- Keeping the team on task/topic
- Paying attention to timeboxes
- Being on time (and first to arrive) to meetings
- Starting/introducing meetings
- Approving the initial time off requests from their team members
- Updating resource guru
- Documenting outcomes from demos on tickets
- Status reporting (schedule, budget)
- Updating the delivery projections for the month
- Onboarding new team members to the dev team
- Coordinating contractors on the project
- Often participating in QA
- Ensuring the team sticks to the scrum format for standups