Lee Sunter MBCS CITP - Agile

• Servant Leader to Product Owner, Development Team and Organisation
• Is to ensure that the scrum team works as well as possible within the scrum framework, responsible for Scrum theory, practices and rules being understood and enacted
• Helps everyone understand which interactions with the Scrum Team are helpful and which ones are not to maximise business value created by the Scrum Team
• They act as coach, active facilitator and protector
• Encouraging the team with daily stand up meetings that help keep the Product Owner’s vision in front of them
• Removing impediments to their efficient work flow
• Where the Product Owner is responsible for the product being created using Scrum, the Scrum Master is the “process owner” who keeps the team on track procedurally.
• Working closely with the Product Owner to keep the product backlog in shape for each sprint
• Work closely with the Product Owner, they help ensure that feature requests, time boxes, and expectations from team members are reasonable within the Scrum framework.
• Scrum Masters also bring insight back to a Product Owner following an unsuccessful sprint to help make the next sprint more successful.
• Neutral

• Coaching the Product Owner on Product Backlog refinement does not mean being the administrative keeper of this artefact
• Coaching the team on self-­organisation and cross-­functionality does not mean taking tasks away from them
• Leading the organisation in its Scrum adoption does not mean publishing status reports
• Every conversation isn't led by the ScrumMaster … including the Daily Scrum

• New ScrumMasters latch on to the mechanics of Scrum
• What’s often overlooked, however, is the people aspect of the job
• Due to the increased collaboration and transparency, organisational impediments and people issues are exposed quickly
• If the problem is not a “Scrum” problem, is it a “people” problem? If yes, then see below

• The first value in the Agile Manifesto begins with Individuals and Interactions
• The Agile Manifesto principles emphasize face to face communication, working together and working with business people daily
• The ScrumMaster ensures helpful interactions occur with the Scrum Team
• Where does the ScrumMaster learn all these people skills?

• How is my Product Owner doing?
• Are Stories or PBIs broken down to the appropriate level?
• Is there enough detail and/or Acceptance Criteria included?
• How is my Team doing?
• Do they have the information, tools, support that they need to meet the Sprint commitments?
• Do they have what the detail that they need from the Product Owner?
• Information Radiators
• Are Task Boards and/or electronic tools up to date with the latest information?
• Do Stakeholders have visibility to information?

• Responsible for determining the overall direction the project will take, what features the product will contain, and what priority each feature will be given.
• Responsible for owning and maintaining the product backlog
• ‘accepts’ items as ‘done’.
• Responsible for ensuring the entire scrum team understands the overall vision for the product.
• Although, it’s important for them to hold back from micromanaging the team and trying to determine exactly how much work will be attempted in each sprint.
• Communicate the goals and return on investment case, refining these over time based on learnings to maximise the success of the product.
• Serves as a conduit carrying communications to and from the scrum team and acting as liaison with upper management and other departments that have a bearing on the project’s success
• Responsible for maintaining a stakeholder network of engaged stakeholder representatives.
• It is advisable to have a Deputy working closely with the Product Owner who can cover in their absence.

Typical Experience

Product Owner responsibilities

• Backlog Grooming – While this is the Product Owner’s responsibility, the Scrum Master is in an excellent position to help the Product Owner groom the backlog. With the results of each sprint retrospective fresh in mind, the Scrum Master can work with the Product Owner to ensure the next sprint is even more in line with reality and set the team up for success.
• Enhancing Team Communication – Working closely with the Scrum Master, who works directly with the team every day, the Product Owner can make sure all necessary communications regarding the project and the product vision are clear to the team, and can carry back any necessary messages to other departments, teams, or levels of the organisation.
• Improving Team Morale – By collaborating throughout a project, the Product Owner and Scrum Master can keep a team’s morale and productivity at the highest levels simply by keeping lines of communication open and setting priorities based on what is reasonable rather than on arbitrary business goals.
• Ensuring Cross-dependencies With Other Teams – Both the Product Owner and Scrum Master likely have close relationships with other teams, other owners and Scrum Masters, as well as past team members that may work elsewhere in the organisation. Leveraging those relationships can help both to improve the current project and smooth any bumps in the road.
• Clarifying the Product Vision – While the Product Owner is responsible for establishing and communicating the strategic vision behind the product, the Scrum Master is responsible for bringing the team on board and making that vision a reality. It makes sense for both to be fully engaged in the vision and be able to clearly communicate it appropriately.
• Facilitating Engaging Meetings – While each role is responsible for various meetings, in practice it can be much more effective for the team to see the Product Owner and Scrum Master switch up the norm in meeting facilitation for the sake of maintaining interest and engagement. Each individual will have their own strengths and personal style in facilitation and can use those differences to bring out the best in each meeting. In the most effective team layouts, the Product Owner and Scrum Master are truly partners in a cohesive and mutually beneficial tag-team effort to get the best possible results from their team’s efforts.

• The team acts collectively to determine how to achieve their goals.
  • The specific features they work on are determined by the priority established by the product owner.
  • Although the agile PO prioritises the product backlog during the sprint planning meeting, the team selects the amount of work they believe they can do during each sprint, and how many sprints will be required.
  • The way they work is guided by the Scrum process, as monitored by the ScrumMaster.
• Everything else is up to the team to manage, with the ScrumMaster providing as much support as needed to allow that to happen. For example, each team member can take a feature from the prioritised product backlog, then decide individually how to execute that work.
• Team members know best what they are capable of, and so they select which user stories from the top of the product backlog they can commit to delivering during any sprint.
  • This level of autonomy is a cornerstone of Scrum. It encourages strong bonds between team members and helps create a positive working environment. While the idea of a team exists in Waterfall projects as well, in that environment the team is functionally managed by the project manager, rather than being self-managed
• The individuals in the team are responsible for ensuring they deliver their work in accordance with the teams definition of done
• The individuals in the team are working towards the team goal rather than individual progress achievements
• The Scrum team's commitment is to complete the selected user stories from the top of the product backlog within the Sprint, (note the product owner makes a reciprocal commitment to not throw new requirements at the team during the sprint).
• Requirements are allowed to change (and change is encouraged) but only outside the sprint. Once the team starts on a sprint, it remains maniacally focused on the goal of that sprint.

• What they have done since the last Daily Scrum.
• What they plan to do before the next Daily Scrum.
• Any impediments (blockers) that they have to their progress

1. The Product Owner explains what Product Backlog items have been “Done” and what has not been “Done”. The Product Owner discusses the Product Backlog as it stands.
2. The Development team demonstrates the work that it has “Done” and answers questions about the Increment.
3. The entire group collaborates on what to do next, so that the Sprint Review provides valuable input to subsequent Sprint Planning.
4. The result of the Sprint Review is a revised Product Backlog that defines the probable Product Backlog items for the next Sprint.
5. Based on the outcomes and feedback, adjustments are made to maximize success and return-on-investment including high level plans and even the product vision.

• Mad, Sad, Glad – three areas representing:
• Mad – things that have annoyed the team
• Sad – things that the team don’t think worked as well as they had hoped
• Glad – things that have made the team happy
• The Sail Boat – a picture of a boat representing:
• Sails or engines – things that are pushing the team towards their goals
• Anchors – things that are blocking or impeding the team from reaching their goals
• The Wheel or Starfish – five sections representing:
• Start – What can we start doing to help our progress?
• Stop – What can we stop doing that is stopping or progress?
• Keep Doing – What can we keep doing because it is helping our progress?
• More Of – What is currently helping our progress that we can do more of?
• Less Of – What is currently blocking our progress and we can do less of?

• Sprint Zero should be used to create the basic skeleton and plumbing for the project so that future sprints can be truly add incremental value in an efficient way. It may involve some research spikes.
• Minimal design up front is done in Sprint Zero so that emergent design is possible in future sprints. This includes putting together a flexible enough framework so that refactoring is easy.
• For minimal design up front, the team picks up a very few critical stories and develops them to completion. Since these are the first few stories, delivering them includes putting the skeleton/framework in place, but even Sprint Zero delivers value.
• Note:
• The velocity (amount of progress/productivity given for a set team) of Sprint Zero may be very low compared to that of other sprints.
• Remember also that the product backlog is a living document. Stories are added, modified, and split into small ones all the time. The backlog can be begun during project initiation. From then it grows and is refined as needed. There should be a few stories in the product backlog at the time of Sprint Zero's start, enough to help us demo at least one working feature. - See more at scrumalliance

• Create A JIRA project and wiki/documentation space
• Start a back log of tasks
• Start initial sizing - story point - for each of the back log items.
• Be clear on the scope of work you are working on - what is it you are trying to achieve?
• Decide on definition of done
• Define skeleton architecture - but write it down even if just a diagram
• Define ways of working and the tools to be used
• Define your environment and the tools to use
• Define what the pre reqs are for developers to become effective on the sprint - ensuring that they have access to all the tooling, access to environments, somewhere to work, are aware of local working practices and any form of developer on-boarding tasks should be completed in this sprint in order to ensure that they can become fully effective from Sprint 1.
• Agree on use of tasks and sub tasks - generally don't use sub tasks as 'harder' to 'manage/use'
• Note sprint 0 tasks can occur throughout the projects! JUST add new tasks to the back log and then priorities the task in the NEXT sprint (it doesn't have to be named 0)
• Decide on where you are going to document details for a task
• Preference is to, up date design documents on a wiki design page rather than providing too much details in the Jira issues/tasks.

• The team we have are mixed skills so cannot do the sprint 0 tasks
• Anyone should be able to size the stories based on their collective knowledge and previous stories
• If you must elaborate some stories to allow the team to start on some work BUT these MUST be related to a MVP/skeleton solution - don't just feed work to the team to keep them busy!
• Spend time up-skilling the team
• Have people understanding the unit testing, mocking, CI environment etc or even writing Jira queries to help with the team reporting.
• Work out the teams workflow - states etc. Work out what fields are needed on the Jira screens etc
• THE key here is to delegate between the team - a sprint isn't a huge amount of time and even if people are not fully busy?
• Start on the elaboration of stories - understand the requirement - create class structure etc?
• Avoid the "We think we have too much work to do - so lets get started!" - diving in approach.
• Firstly work from a fact not just gut feel - how do we do that?
• Create a list (backlog) of all the issues (stories?) that we have to do under the scope - even if this is a very high level list
• Size this list - simply using story points for each story/item on the back log
• Sample one of each story point size to estimate in days - this should give you a value to extrapolate the total effort needed for the scope
• Now you can see when the project will deliver the scope if you divide the total by the number of people and the number of working days to the target end date
• Remember to add effort in for bugs - ~10-20% depends on confidence factor and team
• Remember that you do work fully on issues during the sprint so add some time for that
• Add a hardening sprint to the end if required.