A Scrum Who’s-Who
A Scrum team is composed of 6 +/- 3 members
(a minimum of 3 people to a maximum of 9 people).
There is one basic, recurring question when it comes to setting up a Scrum team: What are the different roles of Scrum team members, and what are their responsibilities? Understanding these roles and responsibilities is essential to assembling an Agile team, and earning their collaboration and commitment.
These roles naturally correspond to different job roles for which one can apply.
A Scrum team always has:
Product Owner
-
The Product Owner (PO) is the representative for the customers and users within the project. There is one PO per Scrum team. The PO is responsible for maintaining and managing the product backlog, which includes the order in which the elements of this backlog will be processed. Backlog elements could be user stories, or features to be developed. In other words, the PO is responsible for the success of the product.
Product Backlog management includes: -
Clearly expressing Product Backlog items;
-
Ordering the items in the Product Backlog to best achieve goals and missions;
-
Optimizing the value of the work the Development Team performs;
-
Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next; and,
-
Ensuring the Development Team understands items in the Product Backlog to the level needed.”
-
The product owner must have a very good product vision and understanding: they must know the product well, and the way in which it should evolve, in order to make sure that the product best adapts to the real needs of customers. They must define the product roadmap.
-
Ideally, the product owner (sometimes called "product manager" although there is no hierarchical authority over the team) is an integral part of the team, they work in the same room, or as close as possible. The PO’s success is highly dependent upon the respect of the organization.
When it comes to a Product Owner job description, what are commonly requested skills?
Some of the most often mentioned skills, other than good knowledge of Scrum and other Agile framework experience, are: -
Translating business objectives into user stories
-
Stakeholder management
-
Creative problem solving skills
-
Ability to technically understand the product
-
Strong leadership, communication, and presentation skills
-
Attention to detail
Scrum Master-
The role of the Scrum Master (SM) is not of a leader who directs his team, rather they should be considered an accompanist. There is no real hierarchy in the Scrum methodology. In managing the progress of the project, the SM makes sure that all members of the Scrum team are involved and know clearly how to organize themselves.
-
A good Scrum Master also shows empathy, diplomacy and humility in order to best solve problems. Also, in order to train and advance the team, they should have teaching skills and work to and improve them.
-
A team working together on a Scrum project must be united. It’s up to the Scrum Master to create harmony among all members. They ensure that there is strong team cohesion by,
-
“Coaching the Development Team in self-organization and cross-functionality;
-
Helping the Development Team to create high-value products;
-
Removing impediments to the Development Team’s progress;
-
Facilitating Scrum events as requested or needed; and,
-
Coaching the Development Team in organizational environments in which Scrum is not yet fully adopted and understood.”
-
The Scrum Master also serves as a link between the product owner and the customer and their team, since the product owner is responsible for communication with the customer. The Scrum Master will indicate to the Scrum team the changes or new options that the client asks for. Other Scrum Master responsibilities.
-
“Ensuring that goals, scope, and product domain are understood by everyone on the Scrum Team as well as possible;
-
Finding techniques for effective Product Backlog management;
-
Helping the Scrum Team understand the need for clear and concise Product Backlog items;
-
Understanding product planning in an empirical environment;
-
Ensuring the Product Owner knows how to arrange the Product Backlog to maximize value;
-
Understanding and practicing agility; and,
-
Facilitating Scrum events as requested or needed.”
-
It is important to remember that the Scrum Master is primarily responsible for the harmony of the team, rather than the content of the project that is in action. The role of the SM covers a wide range of responsibilities--however, the SM is neither a project manager nor a secretary, and that's why it's important that they have these human qualities, as described in the Scrum Guide:
-
“Leading and coaching the organization in its Scrum adoption;
-
Planning Scrum implementations within the organization;
-
Helping employees and stakeholders understand and enact Scrum and empirical product development;
-
Causing change that increases the productivity of the Scrum Team; and,
-
Working with other Scrum Masters to increase the effectiveness of the application of Scrum in the organization.”
-
When it comes to a Scrum Master job description, what are commonly requested skills?
-
Some of the most often mentioned skills, other than good knowledge of Scrum and other Agile framework experience, are:
-
Coaching
-
Basic knowledge of software development, or the project at hand
-
Techniques like user stories, continuous testing, agile games, continuous integration, or pairing
-
Time management, to understand and ensure the product is delivered on time
Development Team
The members of a development team can vary, as each project should be self-sufficient, with the team members’ skills capable of handling the major aspects. In IT projects, these team members traditionally are developers, as they are developing software. As Scrum is being adopted to use in other types of projects, the “developers” can come from a variety of roles. -
-
Development Teams are cross-functional, with all the skills as a team necessary to create a product Increment;
-
Scrum recognizes no titles for Development Team members, regardless of the work being performed by the person;
-
Scrum recognizes no sub-teams in the Development Team, regardless of domains that need to be addressed like testing, architecture, operations, or business analysis; and,
-
Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole.”
-
The number of people on the development team can vary, but as a general rule, fewer is better. This allows for clarity and simplicity while delivering the product. That said, it is important to have the necessary skills represented within the team, or the whole Scrum team could have reduced productivity. The PO and SM are not usually counted as part of the Development team.
-
As for the job description, it is extremely varied. Rather than being hired by title (“Development Scrum Team Member”), members of the development team are usually hired by skill. Development team members generally need to possess the necessary skills for their role in the development of the project only, but it can be beneficial to have experience or expertise in Scrum or other Agile frameworks.
-
-
-
They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality;
-
-
What are the Artifacts of Scum?
The Scrum artifacts are the information that is most important to the Scrum team, as well as stakeholders. There are three main artifacts of Scrum, the product backlog, the sprint backlog, and the increment. There are other artifacts that often make up the Scrum process, but aren’t considered the core artifacts. Two of those are the definition of done, and the burndown chart.
1. Product Backlog
The product backlog takes the product and breaks it into a dynamic list of the required elements, including features, improvements, and fixes. It often has to change to reflect market conditions or business objectives, or feedback from users. This backlog is controlled by the product owner.
2. Sprint Backlog
The sprint backlog takes the specific items from the product backlog that will be focused on during the present sprint and organizes them. It’s a very visible picture of the real-time work of the team. It is flexible as work is completed, to adapt to any tasks that need to be added or that become unnecessary. This backlog is sometimes help set by the product owner and overseen by the scrum master, but it is controlled by the development team.
3. Increment
The increment corresponds to the product increment, a piece of functioning software that is the total of the completed product backlog items from the current sprint and previous sprints. It must be in agreement with the team’s definition of done, and be acceptable to the product owner, who will decide if it will be released.
4. Definition of done
The definition of done is decided by the team and is applicable to most or all of the items in the product backlog. It is a list of criteria to determine when an item should be considered finished. This is helpful to make sure that a completed item will be of high enough quality to be viable, but also to keep the team from spending too much time on a single item.
5. Burndown chart
The burndown chart is used to measure the overall progress of a project. It gives a long term view of completed work and remaining work, essentially counting down--or burning down--the work to zero. It can also track the velocity, and compare the estimated completed work or “burndown” with the actual burndown, giving the team a better sense of what they should realistically plan each sprint.
It is interesting to note that burndown charts generally measure story points, rather than specific items or hours. Story points are an estimation of the effort required for the work, and tasks are rated by the team. Because the work is measured this way, people aren't stuck to dates, and each team can respect their own processes instead of comparing themselves to other teams that work differently.
What are the Ceremonies of Scrum?
The ceremonies in Scrum, or events, are an important part of agile development in a project. The four main ceremonies are meetings that take place during each sprint, and are meant to ensure speedy flow, empower the Scrum team, and continually improve the way of working.
1. Sprint planning
The sprint planning ceremony happens at the beginning of each sprint. They involve the entire scrum team, and are meant to agree upon the work to be done during the sprint. The product owner selects and prioritizes product backlog items, discussing them with the development team. The effort required for the sprint is estimated, as well as setting the sprint backlog.
2. Daily Scrum meetings
The daily scrum meeting is often called the daily stand-up, in which the entire scrum teams comes together for no more than 15 minutes. The team is encouraged to stand up to keep the meeting from running long. The daily meetings are a quick catch-up, meant to inform the rest of the team of the progress and needs of each team member.
All those who wish to cross 'The Bridge of Daily Scrums' must answer:
What they did yesterday?
What they will work on today?
What obstacles they have?
These meetings help increase accountability within the group, improve speed of development, and help the scrum master to know what help the teams need. It’s important that all team members listen and are focused during this meeting, and that the meetings stay on topic without going over the allotted time.
3. Sprint review
The sprint review takes place at the end of each sprint and involves the entire team, but the other stakeholders in the project have the option to attend as well. This ceremony is a showcase opportunity to share what has been completed with the stakeholders and demonstrate the value and functionality.
This is an important moment for feedback from the stakeholders and the product owner.
This feedback will go into the product backlog and worked on in one of the next sprints.
4. Sprint retrospective
The Scrum sprint retrospective occurs at the end of each sprint. The attendees are the development team and the Scrum master. The product owner can attend, but it is not mandatory. The focus of this meeting is to review how the team worked during the last sprint, offering feedback and working together to make tweaks and improvements for future sprints. They also discuss what went well. This is an important step in agile development and should be celebrated every sprint, even if the team is happy and performing well.
5. Backlog Refinement
Product Backlog Refinement is the act of breaking down and further defining Product Backlog items into smaller, more precise items. This is an ongoing activity to add details, such as a description, order, and size. Attributes often vary with the domain of work.
Participants: Product Owner, Developers. Timing: It’s complicated…
During Backlog Refinement, you add more and more details to your Backlog items so that they’re in great shape when you pick candidates for the next sprint during Sprint Planning. Those details may include a clear User Story, Acceptance Criteria and estimated effort.
Unlike the other four ceremonies, there’s no strictly defined time and place for Backlog Refinement. It’s meant to happen continuously throughout the sprint, but some teams opt for a weekly refinement meeting, while others do it several times per week. As a rule of thumb: The less experienced your team or the less time you’ve worked together, the higher the frequency of backlog refinement should be.
What Are the Benefits of Scrum?
The Scrum framework is popular for its ability to create an adaptive process that empowers teams to successfully deliver products in a volatile environment. Some of the main benefits of Scrum are listed below.
1. Adaptability – the Scrum process is iterative and the goal is to release a potentially shippable product at the end of each cycle (sprint). This opens up a feedback loop in the process where teams gather new requirements from customers or adapt to changes.
2. Accelerated Delivery – In Scrum, the time to market is significantly reduced compared to traditional project management. Most cycles (sprints) continue between 2-4 weeks and teams’ goal is to deliver something functional within that period.
3. Improved ROI – Scrum combines frequent market delivery with the idea to release the most valuable functions of a product first. Therefore companies can start realizing profits from a given solution before it’s fully developed. This results in a competitive advantage and increased ROI.
4. Satisfying Customer Expectations – One of the main traits of Scrum teams is that they work in sprints and look to deliver working products frequently. As a result, customers can inspect them early in the process and return their feedback. This contributes to building higher-quality products that meet expectations.
5. Lower Costs – Continuing from the last point, due to the ability to continuously gain feedback, Scrum also allows teams to deal with risks or defects in a timely manner. This reduces the likelihood of reworks which decreases project costs.
What Are the Principles of Scrum?
To successfully embrace the Scrum process, you need to get yourself familiar with its 6 principles.
1.Empirical Process Control – It’s related to making decisions based on observations rather than upfront planning. In other words, empirical approaches are applied to situations where the unknown prevails and there isn’t a laid down path to follow. Empirical process control relies on 3 elements: transparency, inspection, adaptation.
2. Self-Organization – Scrum promotes self-organization rather than micromanagement. This principle stems from the idea that teams are closest to a project’s details so they would have the best judgment on how to execute the actual work. Self-organization also creates a sense of belonging to projects which increases teams motivation.
3. Collaboration – It is related to the idea of constant team interaction in order to deliver the greatest value. It encourages an open environment where everybody is free to share their ideas and work together toward achieving a shared vision.
4. Value-Based Prioritization – To fully satisfy customers, work should be prioritized based on actual business value. This principle is based on the thinking that the most valuable features of a product should be released as early as possible.
5. Time-Boxing – As time is one of the most important constraints in a project, teams using Scrum limit it. This happens through fixed time-boxes for different processes in a project. Those are in the form of sprints which take a certain amount of time (usually 2-4 weeks). This helps teams focus their attention on a specific amount of work and increases their productivity.
6. Iterative Development – It emphasizes the need for iterations when developing products that can change their details alongside the production cycle (ex. software solutions). As new details can emerge during the development process, the idea is to constantly seek customer feedback and use it to adapt to the requirements.
Scaling Up Towards Product Program Level Agile?
In order to be able to use an agile way of working in an organization of some size, just having individual agile teams is in most organizations not enough. There are examples of organizations who have or are in the middle of creating a loosely coupled architecture based on micro services (ex. Bol.com in the Netherlands). Each autonomous agile team manages one or more micro services.
However, in most of the organizations the agile way of working needs to be scaled up, and where possible the overarching alignment needs to be taken care of. This can be done by a project manager or by institutionalizing the coordination.
2004 Agile Project Management (AgilePM)
Agile Project Management (AgilePM, which is derived from Dynamic Systems Development Method, aka DSDM) comes from Agile Business Consortium. It’s a method by which different, possibly permanent, agile teams and non-agile teams are coordinated for the duration of a project.
The AgilePM method for managing agile projects consists of a framework, comprising a philosophy, derived principles, and four building blocks: people, workflows, products, and applications.
The AgilePM philosophy is that every project must be aligned to clearly defined business goals and must focus on the early delivery of products that provide real added value to the business organization.
2005 Large-Scale Scrum (LeSS)
Large-Scale Scrum (LeSS, developed by Craig Larman and Bas Vodde) is an agile framework with rules, based on principles and doing experiments.
The LeSS company offers a freely accessible knowledge base (less.works) containing the integrated approach, principles, process descriptions, definitions, roles, examples, et cetera, for large-scale, mainly IT-related, product development. Transparency is also a key concept within LeSS. The first version dates from 2005 and since then, work is constantly being done on the use and further development of LeSS.
2006 Scrum at Scale (S@S)
Scrum at Scale (S@S, developed by Jeff Sutherland and Alex Brown) is a modular framework. The starting point at S@S is that an all-encompassing one-size-fits-all framework is not possible, but that every time we have to look at scaling the underlying Scrum principles.
The framework can be tailored for your own organization by adding the needed S@S modules. S@S builds on the well-known Scrum framework. By analogy with Nexus you could therefore say that S@S is the answer from Jeff Sutherland, next to Ken Schwaber, the other founding father of Scrum, on the scalability of Scrum.
2009 Scrumban
2011 Scaled Agile Framework (SAFe)
Scaled Agile Framework (SAFe, developed by Dean Leaffingwell) is a framework to enable the scaling up of agile teams in order to create better systems, create higher employee engagement, and make use of correct cost considerations.
This is the mission of the scaled agile organization and of the founder of SAFe, Dean Leffingwell. The scaled agile organization offers a knowledge base that is freely accessible to everyone, with an integrated approach in the form of process descriptions, definitions, roles, examples, etc. for Lean and Agile product development.
SAFe is based on five core competencies: lean-agile leadership, team and technical agility, DevOps and release on demands, business solutions and lean systems and lean portfolio management.
2015 Nexus
Nexus, as described in The Nexus Guide, is a framework for product or software development initiatives with three to nine Scrum Teams, in Sprints of up to thirty days. Nexus is the answer of Ken Schwaber, one of the founding fathers of Scrum, to the scalability of Scrum.
It requires more than just the will and the agile behavior of the different Scrum teams to work together to deliver an integrated product. Nexus is based on and builds on Scrum and the rules and roles formulated in the Scrum guide. We can position Nexus over the team and program levels of SAFe, but it does not offer provsions on portfolio level.
Scrum-Framework Pitfalls
Pitfalls Sprint
-
Using an everlasting Sprint 0 before the "real" Sprints can start
-
Continuously changing the Sprint rhythm
-
Extending the Sprint with a couple of days to ensure a "done" Sprint
-
Using a hardening sprint to tie up the loose ends identified during earlier sprints
-
Not having the same Sprint rhythm, when working with multiple teams on the same product
Pitfalls Sprint Planning
-
Having a Product Owner who doesn't have a Sprint Goal in mind
-
Using a Product Backlog that isn't refined enough
-
Not knowing the velocity and upcoming capacity of the Development Team
-
Not taking the Definition of Done into account when crafting the Sprint plan
-
Ending the Sprint Planning without a shared commitment on the Sprint plan and its goals
Pitfalls Daily Scrum
-
Not doing the "Daily" Scrum every day
-
Considering the Daily Scrum as a status-update towards the Scrum Master
-
Not having a shared and clear Sprint Goal as the main indicator
-
Focus on detailed activities instead of on the actual results the team has achieved
-
Not updating the Sprint Backlog during the Daily Scrum
Pitfalls Sprint Review
-
Considering the Sprint Review only as a demo
-
Demonstrating the results to the Product Owner, instead to the stakeholders
-
Not inviting any stakeholders and hereby neglecting gathering feedback on the increment, Sprint and Product Backlog
-
Canceling the Sprint Review because "there's is nothing to demonstrate"
-
Don't letting the Development Team attend the Sprint Review because they've got more important stuff to do
Pitfalls Sprint Retrospective
-
Cancelling the Sprint Retrospective because "there's nothing the improve"
-
Canceling the Sprint Retrospective because "we don't have enough time to improve"
-
Using the same format over and over again
-
Having far too much ambiguously defined improvements as a result
-
Not having any committed improvements with a clear plan of approach for the upcoming Sprint
Pitfalls of Backlog Refinement
-
Doing not enough Backlog Refinement, which results in a low-quality Product Backlog with lots of ambiguity
-
Doing too much Backlog Refinement, which results in a far too much detailed Product Backlog
-
Considering Backlog Refinement as an activity that includes only the Product Owner and the "Lead Developer"
-
Considering Backlog Refinement as too expensive to spend 10% of the teams capacity on
-
Not involving any stakeholders to clarify specific parts of the Product Backlog
* Backlog Rfinement isn't a Scrum event but an activity. But is added for the sake of completeness.
 |  |  |
|---|---|---|
 |  |  |
 |  |  |
 |  |  |
 |  |  |
 |  |  |
 |  |  |
