Certified Business Analyst
Online Handbook

What is Scrum?

Scrum is a framework that helps teams work together. Much like a rugby team (where it gets its name) training for the big game, scrum encourages teams to learn through experiences, self-organize while working on a problem, and reflect on their wins and losses to continuously improve.

While the scrum I’m talking about is most frequently used by software development teams, its principles and lessons can be applied to all kinds of teamwork. This is one of the reasons scrum is so popular. Often thought of as an agile project management framework, scrum describes a set of meetings, tools, and roles that work in concert to help teams structure and manage their work

What are sprints?

A sprint is a short, time-boxed period when a scrum team works to complete a set amount of work. Sprints are at the very heart of scrum and agile methodologies, and getting sprints right will help your agile team ship better software with fewer headaches.

Sprint planning

Sprint planning is an event in scrum that defines what can be delivered in the upcoming sprint and how that work will be achieved.

The product backlog: your ultimate to-do list

A well-prioritized agile backlog not only makes release and iteration planning easier, it broadcasts all the things your team intends to spend time on—including internal work that the customer will never notice. This helps set expectations with stakeholders and other teams, especially when they bring additional work to you, and makes engineering time a fixed asset.

What is a product backlog?

A product backlog is a prioritized list of work for the development team that is derived from the roadmap and its requirements.

The most important items are shown at the top of the product backlog so the team knows what to deliver first.

The development team doesn’t work through the backlog at the product owner’s pace and the product owner isn’t pushing work to the development team. Instead, the development team pulls work from the product backlog as there is capacity for it, either continually (kanban) or by iteration (scrum).

Start with the two R

A team’s roadmap and requirements provide the foundation for the product backlog.

Roadmap initiatives break down into several epics, and each epic will have several requirements and user stories.

The product owner then organizes each of the user stories into a single list for the development team.

The product owner may choose to deliver a complete epic first Or, it may be more important to the program to test booking a discounted flight which requires stories from several epics

What may influence a product owner’s prioritization?

• Customer priority
• Urgency of getting feedback
• Relative implementation difficulty
• Symbiotic relationships between work items (e.g. B is easier if we do A first)

While the product owner is tasked with prioritizing the backlog, it’s not done in a vacuum. Effective product owners seek input and feedback from customers, designers, and the development team to optimize everyone’s workload and the product delivery.

Keeping the backlog healthy

Once the product backlog is built, it’s important to regularly maintain it to keep pace with the program. Product owners should review the backlog before each iteration planning meeting to ensure prioritization is correct and feedback from the last iteration has been incorporated.

Regular review of the backlog is often called “backlog grooming” in agile circles(some use the term backlog refinement).

Once the backlog gets larger, product owners need to group the backlog into near-term and long-term items. Near-term items need to be fully fleshed out before they are labeled as such.

This means complete user stories have been drawn up, collaboration with design and development has been sorted out, and estimates from development have been made. Longer term items can remain a bit vague, though it’s a good idea to get a rough estimate from the development team to help prioritize them.

The key word here is “rough”: estimates will change once the team fully understands and begins work on those longer term items.

The backlog serves as the connection between the product owner and the development team. The product owner is free to re-prioritize work in the backlog at any time due to customer feedback, refining estimates, and new requirements. Once work is in progress, though, keep changes to a minimum as they disrupt the development team and affect focus, flow, and morale.

Anti-patterns to watch for

• The product owner prioritizes the backlog at the start of the project, but doesn’t adjust it as feedback rolls in from developers and stakeholders.
• The team limits items on the backlog to those that are customer-facing.
• The backlog is kept as a document stored locally and shared infrequently, preventing interested parties from getting updates.

How it keep the team agile?

Savvy product owners rigorously groom their program’s product backlog, making it a reliable and sharable outline of the work items for a project.

Stakeholders will challenge priorities, and that’s good. Fostering discussion around what’s important gets everyone’s priorities in sync. These discussions foster a culture of group prioritization ensuring everyone shares the same mindset on the program.

The product backlog also serves as the foundation for iteration planning. All work items should be included in the backlog: user stories, bugs, design changes, technical debt, customer requests, action items from the retrospective, etc. This ensures everyone’s work items are included in the overall discussion for each iteration.

Team members can then make trade-offs with the product owner before starting an iteration with complete knowledge of everything that needs to be done.

Four agile ceremonies

Sprint Planning

Attendees: Development team, scrum master, product owner
When: At the beginning of a sprint.
Duration: Usually up to two hours per week of iteration. e.g. a two-week sprint kicks off with a four-hour planning meeting.
Agile Framework: Scrum. (Kanban teams also plan, of course, but they are not on a fixed iteration schedule with formal sprint planning)
Purpose: Sprint planning sets up the entire team for success throughout the sprint. Coming into the meeting, the product owner will have a prioritized product backlog. They discuss each item with the development team, and the group collectively estimates the effort involved. The development team will then make a sprint forecast outlining how much work the team can complete from the product backlog. That body of work then becomes the sprint backlog.

Daily stand-up

Attendees: Development team, scrum master, product owner
When: Once per day, typically in the morning.
Duration: No more than 15 minutes. Don’t book a conference room and conduct the stand-up sitting down. Standing up helps keep the meeting short!
Agile framework: Scrum and kanban.

Purpose: Stand-up is designed to quickly inform everyone of what’s going on across the team. It’s not a detailed status meeting. The tone should be light and fun, but informative. Have each team member answers the following questions:

What did I complete yesterday?

What will I work on today?

Am I blocked by anything?

There’s implicit accountability in reporting what work you completed yesterday in front of your peers. No one wants to be the team member who is constantly doing the same thing and not making progress.

Iteration review

Required: Development team, scrum master, product owner

Optional: Project stakeholders

When: At the end of a sprint or milestone.

Duration: Typically 60 minutes per week of iteration-e.g. a two-hour review following a two-week sprint.

Agile framework : Scrum and kanban. Like planning, review for kanban teams should be aligned with team milestones rather than on a fixed cadence.

Purpose : Iteration review is a time to showcase the work of the team. They can be in a casual format like “demo Fridays”, or in a more formal meeting structure. This is the time for the team to celebrate their accomplishments, demonstrate work finished within the iteration, and get immediate feedback from project stakeholders. Remember, work should be fully demonstrable and meet the team’s quality bar to be considered complete and ready to showcase in the review.


Attendees : Development team, scrum master, product owner

When : At the end of an iteration.

Duration : Typically 45 minutes per week of iteration-e.g. a 90-minute retrospective after a two-week sprint.

Agile framework : Scrum and kanban. Scrum teams do sprint retrospectives based on a fixed cadence. Kanban teams can benefit from occasional retrospectives, too.

Purpose : Agile is about getting rapid feedback to make the product and development culture better. Retrospectives help the team understand what worked well–and what didn’t.

Retrospectives aren’t just a time for complaints without action. Use retrospectives to find out what’s working so the team can continue to focus on those areas. Also, find out what’s not working and use the time to find creative solutions and develop an action plan. Continuous improvement is what sustains and drives development within an agile team, and retrospectives are a key part of that.

Agile sprint reviews

Sprint reviews are not retrospectives. A sprint review is about demonstrating the hard work of the entire team: designers, developers, and the product owner.

Team members gather around a desk for informal demos and describe the work they’ve done for that iteration. It’s a time to ask questions, try new features, and give feedback. Sharing in success is an important part of building an agile team.

Step 1: Define of ‘done’

As a regular user of Jira, there’s nothing more satisfying to me than moving a task from ‘code review’ to ‘done.’ That swoosh of an agile card represents completed work we set out to accomplish as a team. Done and done!

A culture of delivery

Effective teams bring clear processes and development culture to each and every work item. Use these questions to assess your process, and make sure it’s working optimally for your team:

• Are stories well-defined by the product owner, designer, and the engineering team before implementation?
• Does everyone understand and live the team’s engineering values and culture?
• Are there clear definitions and requirements around code review, automated testing, and continuous integration to encourage sustainable, agile development?
• After the team completes a story, are there many bugs that surface? In other words, does ‘done’ really mean ‘done?’

The team’s culture around quality and completion should rise above every user story, engineering work item, and bug. This culture is reflective of how the team approaches and delivers software.

Defining ‘done’ on each work item

A clear definition of ‘done’ helps teams focus on the end goal for each work item. When the product owner adds work to the team’s backlog, defining the acceptance criteria is a key part of his or her process. What does it mean for a user story to be complete?

The Jira team tracks acceptance criteria and testing notes right in line with the rest of the user story inside of Jira. That way, the entire team has a clear view of success on every issue. What are acceptance criteria and testing notes?

• Acceptance criteria: metrics the product owner uses to confirm the story has been implemented to his or her satisfaction.
• Testing notes: short, focused guidance from the quality assistance team that enables the development engineer to write better feature code and automated tests.

Having well-defined issues during implementation allows everyone to be successful. With Jira, it’s easy to add fields in line. As an administrator, just click the ‘admin’ button on the issue.

Step 2: Celebrate the team

One of our core values is to “play, as a team.” Sprint reviews are a great time to celebrate the team and everyone’s accomplishments during an iteration.

We typically host them on Friday afternoons, while everyone in the office winds down before the weekend. Sprint reviews are not synonymous with retrospectives, so make sure to host the sprint review after an iteration, but before your retrospective.

External participants are always welcome to join, but the meeting usually consists of the product owner, the full development team, and the scrum master. As a best practice, we recommend spending 30 minutes to an hour for each iteration in the meeting.

We love sprint reviews because they protect the health and morale of the team. Sprint reviews are all about team building. The review isn’t adversarial, it’s not an exam—it’s a collaborative event across the team in which people demo their work, field questions, and get feedback.

If a sprint review doesn’t become a positive activity across the team, it may be indicative of:

• The team taking on too much work and not completing it during an iteration
• The team struggling with existing technical debt
• Features not being developed sustainably to ensure new bugs are not introduced into the codebase
• The team’s development practices aren’t as tuned as they could be
• The product owner is changing priorities within an iteration, and the development team is sidelined by scope creep

Note: every team has a difficult iteration sometimes. Take the time to understand why an iteration changes in the team’s retrospective and create a plan to address issues in the next sprint

Step 3: Reach across geographies

Companies with distributed teams have special challenges around scaling agile ceremonies across geographies. Sprint reviews are no exception.

The Jira team has members across the globe: Sydney, Gdańsk, Saigon, and San Francisco. Even though we’re distributed, sprint reviews are an important part of our team culture.

Team members create informal videos and share them on a Confluence page for the entire team to see. These informal videos keep everyone up-to-date on the progress of development despite time differences. Seeing a feature demo first-hand by the developer strengthens the team in two ways:

• Product Understanding: the entire team gets to hear the intention, rationale, and implementation of the feature. It broadens everyone’s understanding of the entire product.
• Team Building: videos create more personal connections across the team. Each of us gets to see who’s behind every aspect of a product. The bridges created by this practice makes us a tighter, more cohesive group despite geographies.

Stand-ups for agile teams

Stand-ups are one of the fundamental parts of agile development, and it’s often the most misunderstood. Let’s be real: stand-ups by themselves don’t make your team agile.

They aren’t about inflating egos or justifying job descriptions. They aren’t a time to plan; Sprint planning is for planning. They also aren’t the only time to mention blockers. If you’re stuck, ask for help!

What is a stand-up in scrum?

In many sports like (American) football and rugby, the team huddles before each play. The huddle is strategic: it keeps the team informed, connected, and calibrated throughout the game.

For software teams, the stand-up is like the team’s huddle. It’s even commonly known as the daily scrum, and reinforces “we” to keep everyone aware of the team’s landscape and progress.

Said another way, a stand-up is a daily meeting that involves the core team: product owners, developers, and the scrum master. This meeting’s flavor is unique to each team, but at Atlassian we use three simple questions to generate structure:

• What did I work on yesterday?
• What am I working on today?
• What issues are blocking me?

These questions highlight progress and help flag team blockers. Also, it strengthens the team when everyone shares the progress they’re contributing to the team. The daily reinforcement of sharing individual successes and plans keeps everyone excited about the team’s overall contribution to the organization.

At the individual level, it’s important to walk into the day’s stand-up knowing what you’re going to say. It keeps the energy of the stand-up high and everyone engaged. Individuals use Jira boards to keep on top of their projects with quick filters.

Two great filters that can be used together to help prepare for stand-up are “only my issues” and “recently updated.” When these two filters are used together, they show the issues assigned to you and that have been updated in the last day

Stand-ups at Atlassian

Stand-ups are not a one-size-fits-all meeting. Each team has a personalized stand-up to keep everyone involved and engaged. No two are exactly alike.

Let’s dig into what makes a great stand-up, and check out some of our examples.

1. Choose a time that works for everyone – At most stand-ups for co-located teams happen between 9 and 10 a.m. It gives everyone time to get context for the day and doesn’t require everyone to be an early riser on the team. For teams spread across different geographies, choose a time that works for all people. For example, the Jira Service Management team is spread between San Francisco and Sydney. Their stand-up is at 3:30 p.m. San Francisco time. Sure, an afternoon stand-up is a bit non-conventional, but it’s a great way to stay in touch with colleagues across the globe in Sydney.
2. Keep stand-up efficient – Many teams informally time their stand-ups to keep everyone focused and to keep the stand-up efficient. Rotate who keeps time to make sure everyone is accountable and invested. Limit the duration of stand-ups to 15 mins–max. Have a smaller team? Make it a practice to keep the stand-up even shorter.
3. Play catch – The Jira team tosses a beachball between team members to keep everyone engaged. No one can toss the ball to someone next to them or to someone who has already gone. No zoning out! If you haven’t tried the technique, it’s a great way to keep everyone involved.
4. Make the stand-up a part of the team’s retrospective – Stand-ups are part of many agile cultures, but it doesn’t mean that the team can’t discuss the effectiveness of stand-ups in retrospectives. Some teams meet daily. Others meet three times a week. The Jira team regularly discusses how to make stand-ups better for the team in retrospectives. If the team isn’t finding value in a stand-up, discuss why. Make some changes! Stand-ups are agile too!

Stand-ups for distributed teams

Tips for remote stand-ups :

Make team members visual – At Trello, teams use the “Brady Bunch” view on team video calls. This gives visibility to all team members so you can connect with more than just the person that’s talking. Zoom provides this functionality, as do other conferencing platforms.
Reference your scrum board – Gathering “around” your team scrum board can be a powerful way to keep everyone on the same page. Your work board can help visualize each user story and work item as team members share what they’re working on and where they’re blocked.
Be open to asynchronous stand-ups For teams without overlapping work hours, asynchronous stand-ups are the way! Teams can Slack or comments on their work board to share updates as they come online. With Slack and Jira software integrated, you’ll be able to communicate all the info you’d want to get out of a stand-up meeting. Adding a little wink and some personality to asynchronous stand-ups helps keep everyone engaged.

Scrum master

The scrum master helps to facilitate scrum to the larger team by ensuring the scrum framework is followed. He/she is committed to the scrum values and practices, but should also remain flexible and open to opportunities for the team to improve their workflow.

As the title implies, the scrum master is the master of scrum, who ensures the scrum framework is followed. Scrum has a clearly defined set of roles and rituals that should be followed and the scrum master works with each member of the scrum team to guide and coach the team through the scrum framework.

What is a scrum master?

Scrum masters are the facilitators of scrum, the lightweight agile framework with a focus on time-boxed iterations called sprints. As facilitators, scrum masters act as coaches to the rest of the team.

“Servant leaders” as the Scrum Guide puts it. Good scrum masters are committed to the scrum foundation and values, but remain flexible and open to opportunities for the team to improve their workflow.

Scrum master responsibilities

In the ideal agile world, a team would manage its own processes and tools. Yet we’ve found that many teams making the leap to agile often rely on the scrum master as the owner of their process.

It takes time for responsibility and authority to diffuse through a team. In this transformative context, the role can be as lightweight as scheduling the scrum ceremonies or as involved as any other scrum team member.

Although the Scrum Guide lists how the scrum master serves other scrum roles, this is not an exhaustive list of responsibilities. Indeed, we find scrum masters often perform some or all of the following, not all of which are defined by scrum:

1. Standups – Facilitate daily standups (or the daily scrum) as needed.
2. Iteration/sprint planning meetings – Protect the team from over-committing and scope creep. Aid in estimation and sub task creation.
3. Sprint reviews – Participate in the meeting and capture feedback.
4. Retrospectives – Note areas for improvement and action items for future sprints.
5. Board administration – Work as the administrator of the scrum board. Ensure that cards are up to date and the scrum tool, Jira software or otherwise, is working well.
6. 1 on 1s – Meet individually with team members and stakeholders as needed. Iron out team disagreements about process and work styles. While many scrum practitioners are anti-1on1, as they believe these communications should happen during standups, some teams, particularly for new teams, prefer to have these regular face-to-face interactions with specific team members. The scrum master may decide that these individual interactions are crucial for team development and getting to know one another.
7. Internal Consulting – Scrum masters should be prepared to consult with team members and internal stakeholders on how best to work with the scrum team.
8. Reporting – Regular analysis of burndown charts and other portfolio planning tools to understand what gets built and at what cadence.
9. Blockers – The scrum master aids the team by eliminating external blockers and managing internal roadblocks through process or workflow improvements.
10. Busy work – If the scrum team isn’t humming, that’s the scrum master’s problem. Maybe that means fixing broken computers, moving desks around, or even adjusting the thermostat. Scrum masters should be comfortable doing just about anything to help their team and should be not slink away from grabbing coffees or some snacks if that’s what the team really needs.

Do I need a scrum master?

Any scrum trainer will teach that a scrum team must have a scrum master. Without one, you are doing something just shy of true scrum, often called scrum-but.

When starting out with scrum, it can be a huge help to have someone in the role who has seen scrum working before. Better yet, has seen many examples of it working. For this reason, scrum masters are often hired as consultants, rather than as full-time employees.

But every scrum team is different. Many experienced teams handle the responsibilities listed above as a unit, and take pride and enjoyment in a shared management of the process. The role of scrum master rotates through the team, with team members facilitating standups and retros in turn.

And for some teams, the right thing is just to have the same person play the role every day.

Unfortunately, misunderstanding of the scrum master role often leads existing managers to assume it is their role. To better understand why this can be a problem, let’s compare the scrum master to non-scrum roles you may already have in your organization, and why it’s important to keep the role separate.

Scrum master vs. product manager

As we advocate in our Agile Product Management overview, the more involved that a product manager is with the development team, the better. That involvement should be along the lines of a product owner who champions customer needs, the “why” of the product.

When the involvement blurs into tasking, the “how” for a team, then there is a problem. Even with the best of intentions, this kind of utilization mindset tends to hide problems: defects, hand-offs, and unknowns. Interleaving scope and process tends toward locking scope, schedule, and quality. That’s a recipe for failure.

That’s why the scrum master and product owner fill two different needs on a scrum team, that are often combined with traditional software management. And it’s tempting in small teams to avoid the perceived overhead of another role. However, when roadblocks crop up, or changes arise, a clear division between process management and product direction is required.

Scrum master vs. project manager

The scrum master’s non-technical (or non-agile) counterpart is the project manager. Both of these roles focus on the “how” of getting work done and solve workflow problems through process and facilitation. So do you need both? Likely not.

Both a traditional project manager and a scrum master are responsible for helping their teams get work done, but their approaches are vastly different. The project manager sets and tracks timeframes and milestones, reports on progress, and coordinates team communication. However, they do so from a place of control, in a more traditional management role.

The scrum master helps the team enhance and streamline the processes by which they achieve their goals. They do so as a team member, or collaborator, ideally not as someone in control. The best scrum teams are self-organizing, and therefore don’t react well to top-down management.

These are just a few of the possible configurations of scrum team management. Some organizations make due with all of these roles, some have one or none.

Agile Retrospectives

A retrospective is anytime your team reflects on the past to improve the future. Between technical and non-technical teams, you can retro on just about anything!

Distributed scrum: how to manage a remote scrum team

Distributed scrum teams are teams that are either partial or fully remote, who adapt scrum practices for remote work. While scrum provides a framework that can already be useful for remote workers, it’s important to adjust some practices and use the right tools for a distributed team to be successful.

What is a distributed scrum team?

A distributed scrum team is just that — a scrum team that is either fully or partially remote. In order for a distributed scrum team to be successful, new approaches to adopting scrum need to be implemented.

Because of constraints on ad hoc collaboration and informal communication, remote teams need to be more disciplined about their scrum rituals and create new opportunities for bonding and collaboration.

Fortunately, much of scrum’s defined set of rituals, tools, and roles, can be adapted to a remote work environment, including sprints, ceremonies, daily scrums (aka standups), and retrospectives. It’s recommended that a standard agile team follow the “two pizza” rule: teams should be able to be fed by two pizzas, which means teams should be about seven to 10 people.

However, when working remotely, it’s often best to have smaller teams, especially since a video conference with 5 – 6 people is much easier to manage than 10. The traditional scrum roles are just as important with a distributed team but need to make adjustments for the specific challenges of remote work.


• Wider pool of available talent that can increase skill sets of teams
• Teams across geographies that allows for 24-hour workday

Today, some of the best teams are self-organizing, cross-functional agile teams that come from a wide pool of global team members. Companies that allow remote workers can access a wider pool of talent.

As more companies have teams with at least some remote workers, scrum offers a framework to collaborate together effectively. Plus, the adaptability built into scrum that helps teams adjust to changing conditions and user requirements, helps remote teams be agile and constantly learn and improve.

How to build a successful remote scrum team

A remote scrum team should follow the core scrum tenants of clear communication, transparency, and a dedication for continuous improvement.

A remote team’s success depends on mutual trust, communication, and collaboration.

A distributed scrum team can benefit from a solid communication plan that includes:

• Remote work agreements
• A way to contact other team members for informal questions
• Establish agreements for how meetings should be structured
• How team members communicate their availability
• What collaboration tools should be used

Collaboration tools

Effective collaboration tools are essential for all forms of remote working. Agile teams use agile planning tools to collect stories/requirements, report and manage issues, and to track progress and quality.

Distributed teams should have a sort of virtual whiteboard tool that provides visibility of project steps and flow. We use our own tools for that including Jira and Confluence. Whatever you use, this tool should:

• Be accessible to all team members
• Enable collaboration, sharing, and notifications to team members
• A collection of relevant, engaging information
We also use Zoom video conferencing and Slack for impromptu communication. Jira is used for issue tracking, Confluence for team collaboration, and Trello is used to make lists and track progress.

Daily scrum meetings

Daily scrums are an essential part of scrum and even more important for a distributed scrum team. These short, daily team meetings provide a quick forum for a distributed team that helps with focus, collaboration, communication, and problem-solving.

If a team is distributed in different time zones or geographies, it’s important to schedule regular video conferencing. You can also hold asynchronous stand-ups where team members use Slack to check-in or comment on their work board to share updates.

This provides a quick forum for a distributed team that helps with focus, collaboration, communication, and problem-solving.

We use three simple questions to generate a structure for our stand-ups:

• What did I work on yesterday?
• What am I working on today?
• What issues are blocking me?

Product backlog

It’s important that the features of the sprint backlog are clearly documented and “definition of ready” agreed upon. If product backlog items are ambiguous and unclear, the team may lose momentum and the time to resolution can be delayed.

All teams are distributed

In a global organization with multiple offices in different locations, most teams are distributed. Even if only one team member is remote, the team should adopt remote principles to share work between locations, communicate effectively, and maintain a successful culture throughout the organization.

As distributed teams and workplaces grow, it’s important to have clear and concise remote work methods, processes, tools, and ways of working at scale. This can come from adopting agile methods such as scrum, SAFe, LeSS, or whatever works for your business.

For remote teams, Jira Software can help with project planning, management, and ticket tracking by providing visibility to all team members. Trello helps teams build sprints, offer visibility of project status, assign team members, and move projects forward. Scrum teams can also leverage Confluence for building requirements.

Scrum roles

What are the three scrum roles?

Scrum has three roles: product owner, scrum master and the development team members. While this is pretty clear, what to do with existing job titles can get confusing.

Many teams ask if they need to change their titles when adopting scrum. The short answer is no.

Building a scrum team

Scrum is a framework for teams to build their processes on top of. It provides the basic structure for regular meetings, artifacts, and who does what.

What it doesn’t do is provide a one-size-fits-all model for teams to work within. For example, if the team is working on a web insurance application, they will need people who know the technology, the back-end systems, and the business domain.

If, on the other hand, the team is working on the next generation of Donkey Kong, the skills needed would be very different. They would include a graphic designer, sound engineer, and graphics developer.

Because the problems are different, the team structures and skills needed are also different. This gets even harder the more complex the problem a team is trying to solve. As the old saying goes ‘you don’t know what you don’t know, until you know you don’t know it’.

Teams might not know the skills or amount of work needed up front, and need the flexibility to change course once they know more.

The development team: Redefining developer

The development team are the people that do the work. At first glance, you may think the “development team” means engineers. But that’s not always the case. According to the Scrum Guide, the development team can be comprised of all kinds of people including designers, writers, programmers, etc. You can think of it in the same way as when you have a house project and you hire a developer. They develop the project and do the work. Yes, this might mean they lay bricks, do plumbing, even dig holes, but the person is known as a developer. So, that means the ‘developer’ role in scrum means a team member who has the right skills, as part of the team to do the work. The development team should be able to self-organize so they can make decisions to get work done. Think of a development team as similar to a production support team that is called in during the night because something has gone wrong.

The development team, like the production support team, can make decisions and deliver the fix/value for the problem at hand. Self-organization isn’t about disrespecting the organization, but rather about empowering the people closest to the work to do what’s needed to solve the problem.

The development team’s responsibilities include:

• Delivering the work through the sprint.
• To ensure transparency during the sprint they meet daily at the daily scrum ( sometimes called a standup). The daily scrum provides transparency to the work and provides a dedicated place for team members to seek help, talk about success and highlight issues and blockers.
• The scrum master might facilitate the daily scrum, but ultimately it is the responsibility of the development team to run this meeting. It is their meeting to help them, as a group, to inspect and adapt the work they are doing and work in a more effective way.

The product owner: Setting clear direction

Agile teams are, by design, flexible and responsive, and it is the responsibility of the product owner to ensure that they are delivering the most value. The business is represented by the product owner who tells the development what is important to deliver.

Trust between these two roles is crucial.
The product owner should not only understand the customer, but also have a vision for the value the scrum team is delivering to the customer. The product owner also balances the needs of other stakeholders in the organization.

So the product owner must take all these inputs and prioritize the work. This is probably their most important responsibility because conflicting priorities and unclear directions will not only reduce the effectiveness of the team, but also could break the important trust relationship that the business has with the development team.

Agile teams are designed to inspect and adapt. That means a change in priority may lead to a massive change to the team structure, work products, as well as the end result. It is, therefore, crucial for scrum teams to be successful and that only one person sets priority. That person is the product owner.

The Scrum Guide defines the product owners responsibilities as:

Managing the scrum backlog – This does not mean that they are the only one putting in new product backlog Items into the backlog. But ultimately they are responsible for the backlog that the development team pulls to deliver from. That means the product owner should know about everything that is in the backlog and other people that add items to the product backlog should ensure that they communicate with the product owner.
Release management – The sprint is not a release cycle, but instead a planning cycle. That means that scrum teams can deliver at any time. Ideally, they would deliver frequently throughout the sprint allowing the sprint review to review real customer usage and feedback. However continuous delivery is not always possible and other release models are required. It is important for the product owner to know when things can and should be released.
Stakeholder management – Any product will have many stakeholders involved ranging from users, customers, governance and organizational leadership. The product owner will have to work with all these people to effectively ensure that the development team is delivering value. That can mean a large amount of stakeholder management and communication.

The scrum master: Holding it all together

The scrum master is the role responsible for gluing everything together and ensuring that scrum is being done well. In practical terms, that means they help the product owner define value, the development team deliver the value, and the scrum team to get to get better.

The scrum master is a servant leader which not only describes a supportive style of leadership but describes what they do on a day-to-day basis.

They serve the product owner by helping them better understand and communicate value, to manage the backlog, help them plan the work with the team and break down that work to deliver the most effective learning.

Serving the development team, the scrum master helps them self-organize, focus on outcomes, get to a “done increment,” and manage blockers. The scrum master also serves the organization at large, helping them understand what scrum is and create an environment that supports scrum.

The scrum master focuses on:

Transparency – To effectively inspect and adapt it is important that the right people can see what is going on. But this is actually much harder than it looks. The scrum master is tasked with ensuring that the scrum team works in a transparent way. Examples include creating story maps and updating Confluence pages with retrospective ideas.
Empiricism – A fundamental for scrum and agile approaches the idea that the best way of planning is to do work and learn from it. The empirical process is not easy and requires the scrum master to coach the scrum team on breaking down work, describing clear outcomes, and reviewing those outcomes.
Self-organization – Telling a development team they can self-organize does mean that the team will self-organize. In fact, self-organization comes over time and requires help and support. The scrum master will encourage team members to step outside their comfort zone and try different things and use practices such as ‘delegation poker’ to expose and challenge predefined ideas about role boundaries and responsibilities.
Values – Scrum defines 5 values of courage, focus, commitment, respect, and openness not because they are nice to have, but because they create an environment of physiological safety and trust. This environment is necessary for agility to thrive. Following the values is the responsibility of everyone in the scrum team, but the scrum master takes an active role in encouraging and reminding everyone of the importance of those values.

The scrum master serves the product owner in sprint planning and sprint reviews, ensuring that value is clearly being described and direction set. They serve the development team in the daily scrum by ensuring that work is happening and that blockers are being removed.

They also take responsibility for blockers that are outside of the team’s ability to resolve. The scrum master ensures that every opportunity to improve is made transparent to the scrum team and the retrospective has a clear set of outcomes that can be executed.

Get started with agile scrum roles

The three scrum roles are pretty simple in describing the three major areas of responsibility on any scrum team, but often it is hard to map them to your own job title. So here is a starter:

• If you have lots of great skills for delivering customer value and that is what excites you, then you should be a scrum development team member. In fact, the team is the most important element of any agile organization as they actually deliver value to customers and stakeholders. That means that seniority is determined by how much you deliver value or help others do it.
• If you are passionate about the customer, managing stakeholders, and the business domain, then the product owner role would be best suited to your desires. In most organizations, this person needs to have the respect and trust of the business, so they can make decisions. The role also requires some level of politicking as you negotiate trade-offs and keep everyone happy.
• If you want to help teams work effectively together and also want to change the world with scrum and agile, then the scrum master role is for you; a very people-centric role with a heavy emphasis on coaching, teaching, and facilitation.
WhatsApp chat