What is the function or purpose of management in Scrum

What is the function or purpose of management in Scrum?

If you're a Scrum Master or Product Owner, you've probably heard the term "management" thrown around a lot. But what exactly does management do in Scrum? And how can they help your team be more successful?

In this blog post, we'll take a look at the role of management in Scrum and discuss some of the ways they can help their teams. We'll also provide some tips on how to be an effective manager in Scrum.

So whether you're new to Scrum or you're looking for ways to improve your team's performance, read on for some valuable insights.

Unlock the secrets of becoming a top Scrum Master with our all-in-one guide, designed to equip you with the knowledge and tools you need to thrive in this fast-paced career.

 

Management's role

Management's role is to be the bridge between the Product Owner and the rest of the team. They're responsible for providing valuable information and knowledge on top-tier product and system capabilities, and for helping the Scrum Master promote organizational transformation that nurtures empirical thinking, self-governance, grassroots intelligence, and intelligent product delivery.

In other words, management is there to help the team succeed by providing them with the resources they need and by creating a supportive environment. They're also there to help the Scrum Master keep the team on track and to make sure that the team is always learning and improving.

So, what does that mean for managers in Scrum? Well, it means that they need to be able to think strategically, to be able to communicate effectively, and to be able to build relationships with people. They also need to be able to be flexible and adaptable, as things are always changing in Scrum.

If you're a manager who's thinking about adopting Scrum, then there are a few things you need to do to prepare. First, you need to learn as much as you can about Scrum. There are a lot of resources available online and in books. Second, you need to talk to your team and get their buy-in. Scrum can be a big change for teams, so it's important to make sure that everyone is on board. Third, you need to start making some changes to the way you work. Scrum is a very different way of working, so you'll need to make some changes to your processes and your way of thinking.

If you're willing to put in the effort, then Scrum can be a great way to improve the way your team works. It can help you to be more agile, more responsive, and more successful.

So before we get into that, let's first review the two roles. 

The Product Owner

The Product Owner, is an individual who is responsible for managing a product backlog of all the user stories that need to be developed or implemented. 

Also, this person is accountable for ensuring that each story has been properly prioritized so that the team can implement it promptly. However, this person does not write the code or implement the stories. Instead, they act as the main interface between the development team and stakeholders. 

The Product Owner is considered a special Agile team member because they have additional responsibilities outside of development. They manage the backlog, determine what features get built, and consider feedback from users and stakeholders when prioritizing the backlog. Therefore, this person must possess a wide range of skills to perform their role effectively. 

The Scrum Master

The Scrum Master, is a person who is responsible for helping the team and organization transition towards Agile practices. Also, they coach the team on how to use Agile practices to improve product development cycles. 

They also help team members learn how to work more effectively as a cohesive unit. 

Lastly, they help create an environment where Agile software development techniques can thrive by coaching and facilitating discussions about Agile principles and practices with team members and other stakeholders. 

Now that you know what Product Owner and Scrum Master are, let's look at what management should do in Scrum. 

Management In Scrum: Helping The Team And Organization Transition Towards Agile Practices  

As a manager, you're in a unique position to help your team transition to an Agile way of working. Here are a few things you can do to help:

• Support the team as they embrace Scrum. Talk to them about the benefits of Agile, and help them to understand the concepts and practices of Scrum.
• Coach and facilitate discussions about Agile principles and practices. Help team members to understand the Agile Manifesto, and to apply the principles of Agile to their work.
• Help the team use Agile practices. Daily standups, daily status updates, burndown charts, retrospectives, incremental development, sustainable pace - these are just a few of the Agile practices that can help your team to be more successful.
• Track progress by using burndown charts. Burndown charts can help you to visualize how much work has been completed, and to identify any potential problems.
• Facilitate discussions about quality Agile software development practices with stakeholders and users. Help stakeholders and users to understand the importance of quality, and to work with the team to develop and implement quality practices.
• Help the team to define the Definition of Done. The Definition of Done is a set of criteria that must be met before a product can be considered complete. Help the team to define what the Definition of Done means for them.

By taking these steps, you can help your team to transition to an Agile way of working and to reap the benefits of Agile.

flowchart that illustrates the different roles of management in Scrum

The flowchart starts with the Product Owner, who is responsible for defining the product backlog and prioritizing the work. The Scrum Master is responsible for facilitating the Scrum process and ensuring that the team is following Agile practices. The Development Team is responsible for building the product.

The flowchart shows how the different roles interact with each other. The Product Owner works with the Scrum Master to prioritize the work, and the Development Team works with the Scrum Master to plan and execute the work. The Scrum Master works with the Development Team to help them to be more agile.

The flowchart also shows the different responsibilities of each role. The Product Owner is responsible for defining the product backlog, prioritizing the work, and communicating with stakeholders. The Scrum Master is responsible for facilitating the Scrum process, ensuring that the team is following Agile practices, and coaching the Development Team. The Development Team is responsible for building the product, testing the product, and releasing the product.

The flowchart is a helpful visual aid that can help to illustrate the different roles of management in Scrum. It can also help to show how the different roles interact with each other and what their responsibilities are.

How management can help to improve the efficiency and effectiveness of Scrum teams

specific examples of how management can help to improve the efficiency and effectiveness of Scrum teams:

• Organizing and coordinating the work of the team. Management can ensure that the team has a clear understanding of what needs to be done and that everyone is working towards the same goals.
• Providing resources and support. Management can provide the team with the resources they need to get their work done, such as tools, equipment, and training. They can also provide support to the team, such as emotional support and guidance.
• Motivating and inspiring the team. Management can motivate and inspire the team to do their best work. They can do this by setting clear goals and expectations, providing positive feedback, and creating a positive work environment.
• Measuring and evaluating the team's progress. Management can measure and evaluate the team's progress towards their goals. This information can be used to identify areas where the team is doing well and areas where they need to improve.
• Adapting and adjusting the plan as needed. Management can adapt and adjust the plan as needed to ensure that the team is on track to achieve their goals. This may involve making changes to the team's work plan, the team's resources, or the team's goals.

Timeline that shows the different phases of a Scrum project

The timeline shows the different phases of a Scrum project, from the planning phase to the development phase to the release phase. The planning phase is where the Product Owner and the Scrum Master work together to define the product backlog and to prioritize the work. The development phase is where the Development Team builds the product. The release phase is where the product is released to the stakeholders.

The timeline also shows the different activities that take place in each phase. In the planning phase, the Product Owner and the Scrum Master work together to define the product backlog, to prioritize the work, and to communicate with stakeholders. In the development phase, the Development Team builds the product. In the release phase, the product is released to the stakeholders.

The timeline is a helpful visual aid that can help to illustrate the different phases of a Scrum project. It can also help to show the different activities that take place in each phase.

Here is a more detailed description of each phase:

Planning Phase

The planning phase is where the Product Owner and the Scrum Master work together to define the product backlog, to prioritize the work, and to communicate with stakeholders. The Product Owner is responsible for defining the product backlog, which is a list of all of the features that the product will have. The Scrum Master is responsible for prioritizing the work, which means deciding which features should be worked on first. The Product Owner and the Scrum Master also communicate with stakeholders, which means keeping them informed about the progress of the project.

Development Phase

The development phase is where the Development Team builds the product. The Development Team is responsible for taking the features from the product backlog and building them into the product. The Development Team also tests the product to make sure that it works properly.

Release Phase

The release phase is where the product is released to the stakeholders. The Product Owner and the Scrum Master work together to release the product to the stakeholders. The Product Owner is responsible for making sure that the stakeholders are happy with the product. The Scrum Master is responsible for making sure that the stakeholders are able to use the product.

How To Establish A Definition Of Done That Works For Your Team And Organization 

It's important for teams to have a definition of done (DoD) so that they know when an item is complete. 

For example, if a user story is about implementing a new feature, then the definition of done would be when it has been successfully implemented into production. However, it's important for Product Owners and Scrum Masters to actively facilitate discussions about DoDs so that teams clearly understand their responsibilities in defining them. 

Furthermore, because your team's DoDs will vary depending on the product type you're working on, it's important to remember these things when defining them:  

1. Is this a linked-in profile? 
2. If so, there are specific DoDs appropriate to this type of product. Is this an e-commerce website? 
3. If so, then different DoDs apply to this type of product. Is this a mobile app? 
4. If so, then different DoDs still apply to this type of product. 

As you can see, it's important for management to help teams define their DoDs, considering the type of product they're doing. This will help ensure that teams define their DoDs in a way that works for their team and organization. 

So now, let's look at how you can define your DoDs for your teams. 

How you can define your DoDs for your teams

The Definition of Done is a key part of Agile software development. It's a set of criteria that must be met before a product can be considered complete. But what does that mean, exactly? And how do you establish a Definition of Done that works for your team and organization?

Here are a few tips:

• Define business rules. What are business rules? They're anything related to business processes and policies mandated by your organization or stakeholders, such as compliance requirements for data privacy or security issues related to personally identifiable information (PII).
• Define sprint goals. Next, you must define sprint goals aligning with Agile principles like empiricism and incremental development.
• Get everyone on the same page. It's important to get everyone on the team, from the Product Owner to the Scrum Master to the developers, on the same page about what the Definition of Done means. This will help to avoid confusion and misunderstandings down the road.
• Be flexible. The Definition of Done is a living document. It should be updated as needed to reflect changes in your team's processes, the project's requirements, or the team's understanding of Agile principles.
• Get feedback. Don't be afraid to get feedback from your team and stakeholders on the Definition of Done. They may have insights that you haven't considered.

By following these tips, you can establish a Definition of Done that works for your team and organization and helps you to deliver high-quality software on time and within budget.

Great Scrum Masters

Great Scrum Masters manage teams that can hit their goals every single sprint. One way to do that is to have an ideal velocity every sprint. A superior velocity is based on historical data and past velocity charts that show how much work has been done per sprint over a certain period. 

It's not the number of hours worked but more like story points completed per sprint.  

1. Ideal Velocity: The number of story points (ideal hours) completed per sprint  
2. Ideal Velocity = Actual Velocity / Sprints per Year Actual Velocity: The number of story points (ideal hours) completed per sprint  
3. Average Sprint Length: The average number of days per sprint  
4. Average Sprint Length = Total # of Sprints / Number of days in each sprint  
5. Total # of Sprints: The total amount of time spent in Scrum You can use this formula to calculate ideal velocity; it's a helpful baseline for gauging how well your team is performing each sprint. 

If your team can get its average velocity above the ideal velocity benchmark, it delivers more value than expected from each sprint. If your team is producing less than perfect velocity, they are not delivering additional value as often as they should be. 

Ideal velocity

Ideal velocity should be higher every sprint due to increased productivity and efficiency, but it doesn't always happen that way. A good Scrum Master will try to help teams deliver more value per sprint by setting targets for the groups and helping them understand the concept of ideal velocity and actual velocity so they know where they are currently performing concerning that goal. 

The Goal Setting Workout  

To help your team reach its ideal velocity, you need to ask yourself three questions: 

• What is our current ideal velocity? 
• Is it going up? Is it going down? 
• What factors affect our ideal velocity? 
• What can we do differently as a team? 
• Can we improve our standups? 
• Can we improve our planning sessions? 
• Can we improve our retrospectives? 
• What roles can we remove from our teams? 
• In what ways can we optimize our existing process? 

Those questions will drive your goal-setting workouts throughout the year so you can get your teams better at hitting their goals every sprint. Goal Setting in Scrum

Goals for great managers

Goals are essential for great managers, and communicating those goals to Scrum teams is crucial. Goals keep organizations moving forward, whether that organization is a sports team or technical product development organization like a startup or large enterprise organization making an upgrade or migration project happen. 

Goals motivate humans incredibly when they are challenging goals that stretch people beyond their comfort zone. Goals keep people focused on specific tasks and allow them to get feedback on their performance as they go along—the early feedback loop concept I mentioned earlier in this section applies here, too, because goals allow managers and leaders to see if their teams are performing at the levels they need them too if those teams are not performing at the levels required then the leaders can act—adjusting the strategy or even making changes—to help those teams perform better next time around.

 

Types of goals

In any organization, there are many different types of goals for many different types of organizations: marketing goals, sales goals, project management goals, dev ops goals, and business goals. 

Understanding how to create and communicate these goals is a key attribute of management in Scrum. A key aspect of improved management in Scrum is the development of strong planning skills. These skills are not well developed in modern business schools today and are better learned through on-the-job experience. 

But that's OK since these skills can be learned on the job as part of your daily work if you embrace Agile management and apply its practices every day. 

What is Agile Management? 

Agile management is based on the practice of agile development. It is a way of working with teams to develop products or services in short iterations that are quickly deployed and immediately released to customers for feedback. 

This iterative approach to product design has resulted in products like the iPhone, Android, and Amazon Kindle. 

It is a way of thinking about how organizations can improve their products and services by exposing them to customers for feedback. 

It requires an environment where teams can quickly respond to change rather than an environment where managers make decisions about future work without input from the teams implementing them. 

Culture 

Agile management requires a culture that values customer feedback above all else and a leadership that embraces transparency and daily team collaboration. A culture with Agile management practices is biased towards action rather than meetings or documents. 

It has a bias towards shipping software instead of analysis. It has a bias towards experimentation instead of debate. 

Why Agile Management? 

The agile development cycle described above is a proven way to develop successful products, but how does agile management apply to organizations other than software companies? 

Managers can apply Agile management to any organization where teams deliver customer value, such as consulting firms, financial firms, and advertising agencies. 

The key difference between these organizations and software companies is that software y is delivered through code, which needs to be written before it can be delivered. Still, other organizations deliver value through presentations, proposals, reports, contracts, etc., all written after the work. 

The fundamental problem with traditional hierarchical management structures is that they require too many meetings and documents that slow down the process of getting work done by feature teams and then deploying it to customers for feedback. 

As we'll see later in this article, Agile management enables feature teams to complete their work faster by eliminating some bottlenecks. 

Release early

These teams can then iterate quickly by releasing early and often to experiment with different approaches before deciding which works best for their customer base. 

Traditional hierarchical structures require approvals from on high which adds time between when a feature team completes an iteration and when they get feedback from customers; this impedes the iterative process by slowing down delivery cycles. 

Agile Management: Planning at Scale 

The fundamental problem with Agile development is that it was originally designed for small teams with small projects that a team can complete in short iterations with minimal risk. 

Yet Agile has now become synonymous with large project planning at large companies like IBM and Microsoft, which have adopted the term "agility" to describe their efforts to produce more rapid product releases on a much larger scale than ever before; teams once thought projects like this were impossible because they were considered too large for small iteration cycles. 

Yet these large companies have succeeded by making incremental improvements that collectively add up over time; they have been able to make these improvements because they have committed leadership that understands how Agile works at scale. 

Agile management may be difficult, but it isn't rocket science; I'll explain how you can apply it today to enjoy the benefits it brings your organization tomorrow! 

Understanding how Agile works at scale

Step one is simply understanding how Agile works at scale by applying some basic principles underlying its success:

1. Small Teams
2. Teams need to be small enough so that there are fewer than 10 people per team
3. Teams should ideally have fewer than 5 people per team
4. Teams should ideally have fewer than 3 people per team
5. Short Sprints
6. Sprints should be planned for no more than 2 weeks; sprints longer than 2 weeks should only be used for very large projects Sprints should ideally be planned for no more than 1 week; sprints longer than 1 week should only be used for very large projects
7. Iterative Release Cycles
8. Sprints need to be aligned with release cycles
9. Release cycles should ideally be weekly or bi-weekly

Collaboration

Collaboration between teams must be encouraged; this helps eliminate dependencies between teams

In addition to following these basic principles, there are also some specific techniques that you can use when creating your backlogs or planning your releases (for more information about backlogs please refer to Sprint Planning: What Is It?). 

Creating Backlogs 

The First Step Towards Agile Management Let's start with backlogs because they are the first step in creating an Agile environment; they are the backlog of work that teams must plan out each sprint so they know what features they need to deliver during that sprint to meet their release milestones in the coming sprints during the upcoming release cycle(s). The key thing about backlogs is that they must be kept small so you don't create dependencies between teams during implementation cycles (which would slow things down). 

This means each backlog must contain only features that will get completed during a single sprint so nothing slips back into future sprints (which would create dependencies); it also means each backlog must contain only features which have dependencies that other feature teams have already committed to implementing during future sprints (which means you need some history if you want this type of backlog). 

Let's look at examples of how this might work in practice:

What Do You Mean By "Backlog?" Does That Mean I Need To Be Writing Things Down? Achieving Scrum Without Any Documents? Head scratchers like this were common when I began experimenting with Agile development almost ten years ago! They were common because most software developers didn't understand what "backlog" meant in Agile parlance; most software developers thought backlog meant writing out everything you plan on doing during future sprints on pieces of paper or wiki pages so people could see what was coming up next (which is not what backlog means). 

Of course, this leads us back to our main point about why many software developers think Agile is hard: most software developers do not understand what "backlog" means! Software developers tend towards linear thinking when it comes to planning because software design often involves building things from scratch out of thin air—software developers sometimes think you have to plan everything out in advance before you can start implementing new features in your product (which is not true). The reality is agile development requires incremental planning while working incrementally—it requires short planning cycles (aka "sprints") followed by short iterative delivery cycles (aka "releases") until you reach your release milestones (and then repeat)! Each sprint must deliver something new, forcing you to plan incrementally while working incrementally; if you don't, your backlog will get too big too fast! 

And if the planning gets out of hand or becomes too complex, you have many meetings where people argue over what features should be released next.

Fast, easy, and clear

Great managers make release planning fast, easy, and clear to everyone on the Scrum Team. The best release plans are simple and easy for everyone to understand. Good release plans contain enough detail for teams to know what items must be developed to deliver customer value. Release planning should be a simple, straightforward process. There is no need to spend hours preparing elaborate slide decks or documents. 

A Product Owner may want more detail, and that's fine, but the daily Scrum Team shouldn't need it. 

The goal of release planning is to break the estimate into small increments so the team can deliver an increment every one or two weeks. Ideally, a customer would see an improvement in the product each week. So, if you have a 50-item backlog, you might want to break it into something like 25 items per sprint and five sprints per release. 

The exact number of items in a sprint depends on the short development cycles used by your team. In theory, the number of items in a sprint is irrelevant, though there is probably some range that works best for the team in practice. Sprint planning happens once per iteration; release planning happens once per release cycle (likely once per iteration). Prioritizing Backlog Items for Release Planning To sequence work effectively, you need to understand what value an item provides and who will value it most highly. 

In other words, you need to prioritize your backlog. Don't panic, though! 

Prioritizing backlog items

Prioritizing backlog items doesn't have to be hard! Just think about how you break down the backlog into features, epics, and tasks. And remember: The backlog is not done until it's prioritized! I like using two dimensions (and their inverse) along with a weighting factor to rank backlog items:  

1. Must-have
2. Should-have
3. Nice-to-have
4. Won't-have
5. Impossible-to-implement
6. Rejected. 

 

Must-Have

These things are required for shipping the product, so they always go first in a release plan. Also, Must Haves has considered product backlog items (required for shipping) and, therefore, must never get bumped by anything else in scope for an iteration or release cycle. Must-Have: Product Backlog Item Requirements Must Be Implemented in This Release Cycle  

Should Have

Products have these attributes when desired by your target market, and customers value them highly enough to pay money or volunteer information in exchange for them. 

These requirements should be high on your list of things that ship in every release cycle (at least initially).  

Nice To Have

These things aren't necessarily required for shipping yet, but they might be nice depending on the situation. If you don't have time to implement them now but might someday – those are nice-to-haves. If they aren't needed by anyone but add value anyway – those are nice-to-haves too!  

 

Won't Have

This bucket contains all things that won't ever get implemented because they don't make sense or aren't needed right now, like better network protocols or more efficient algorithms.  

Impossible To Implement

This bucket contains completely impossible things to implement because they violate one of your fundamental design principles or business rules about the product or service (like needing a smartphone before building a smartphone app!). 

Rejected

his bucket contains everything the team rejected due to technical limitations imposed by your architecture or design – like building an airplane with concrete nails instead of aluminum bolts, it just doesn't happen! Weighting Must Haves vs. Should Haves & Nice To Haves You can optionally apply weights to Must Haves, Should Haves & Nice To Haves, and Won't Haves & Rejecteds so that they carry more importance than others when prioritizing work during release planning sessions. 

Use weights sparingly, though – overuse can create conflicts because people will wonder why one item has twice the weight as another with only slightly less priority and try arguing why something with twice the weight shouldn't go first! Use weights judiciously and only when necessary – if you use weights, then make sure you assign them at the beginning of a release planning session and stick with them throughout that cycle! If you don't use weights, ensure everyone understands how the product owner assigned weights during backlog review sessions! Weighted Priority Tiers Align With WIP Limits The prioritization tiers from highest priority down through lower priorities align directly with the WIP limits of the Scrum Master and Product Owner (if applicable), so you can use them instead of numbers (or back them up with numbers); for example "Must Have: Product Backlog Item Requirements Must Be Implemented in This Release Cycle; Won't Have: Won't Ever Be Implemented due to Technical Limitations; Rejected: Rejected Due to Current Technical Limitations Imposing Limits On What Is Possible And what isn't possible." It's OK if there is duplication between these labels and numbers; confidence comes from consistency, at least until there becomes too much inconsistency! 

It All Comes Down To Prioritization Isn't Easy There is no recipe for developing good backlogs; it's difficult to work requiring good judgment about what constitutes valuable requirements for implementing products and services customers want and need - even more importantly - will pay to get!  

It took me several years of studying various Agile frameworks before I understood why some parts of Scrum made me uncomfortable; I was trying desperately not to create artificial lists of tasks my team had to complete each iteration instead of letting the team decide how they would build great software products together each step at a time while discovering new ways of doing so incrementally as we got feedback from our market and customers along the way! Release Planning = Sprint Planning + Bigger Increments  

As stated above, release planning involves breaking down estimates into small enough increments such that teams can deliver an increment every 1 or 2 weeks(ish), making releases small enough that customers see value continuously improving over time while keeping teams focused on delivering increments according to their Sprint planning commitments without having to worry about whether we can do everything we want this cycle without compromising future cycles. 

The major difference between Sprint and Release planning is that Release planning attempts to accommodate current development cycles, iterations, and releases! Estimating Release Cycles For teams to keep up with their commitment during Sprint Planning sessions, teams must understand how long their current development cycles take – especially since many teams have multiple parallel streams of work where work may overlap, and multiple Development Teams may share development cycles; those teams must determine which subset of tasks fit within their current development cycles so that others don't get pushed back unnecessarily – especially when working toward release deadlines! 

Fortunately, there are simple ways for teams who use Kanban boards like Trello™ can track their progress within their existing backlogs without adding any new columns or tasks specifically designed for this purpose - just an additional column called "Development Cycle," which is equal to size (in width) as any other column including "Tasks Done" which makes it easy to track how many tasks are done per day/week/iteration/release cycle(s). 

When looking at Trello cards on Kanban boards, cards with longer development cycles get taller relative to shorter development cycles making it easy to tell how much work remains before something is done(!). Kanban boards also make it straightforward to show where in your workflow things get blocked since cards get stacked up behind physical blockers, thus reducing bottlenecks or ensuring work gets done faster since developers can see exactly what bottlenecks exist behind particular cards, thus gaining insight into efforts needed to reduce bottlenecks as well as tracking progress against previously scheduled release dates.

In conclusion

In this tutorial you learned that managment supports and assists the Scrum team in delivering great capability faster and at a lower cost by focusing on the doing Scrum properly.

Related content

1. Scrum Master Certification
2. Sprint planning
3. Daily scrum
4. Guide
5. Sprint review
6. Sprint retrospective
7. Velocity
8. https://www.goagileworks.com/blogs/news/learning-scrum-master-role-in-agile-team
9. https://www.goagileworks.com/blogs/news/mastering-scrum-master-responsibilities
10. https://www.goagileworks.com/blogs/news/developing-agile-mindset
11. https://www.goagileworks.com/blogs/news/building-strong-relationships-with-team-members
12. https://www.goagileworks.com/blogs/news/exploring-agile-methodologies

You can also find Jon writing about drinks at Mixed Drink Artist where he covers topics like

• What Does an Old Fashion Taste Like
• Best Rums for a Pina Colada
• Simple Syrup
• Absinthe