What is scrum?
Scrum is an agile project management framework that helps teams structure and manage their work through a set of values, principles, and practices. Scrum encourages teams to learn through experiences, self-organize while working on a problem, and reflect on their wins and losses to continuously improve.
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.
We'll discuss how a traditional scrum framework is comprised with the help of the [Scrum Guid](https://www.scrumguides.org/)
Agile vs. Scrum
Don't get confused that agile and scrum both are same thing, scrum is centered around continuous improvement, which is a core principle of agile. However, scrum is a framework for getting work done, whereas agile is a philosophy. The agile philosophy centers around continuous incremental improvement through small and frequent releases. You can't really "go agile", as it takes dedication from the whole team to change the way they think about delivering value to your customers. But you can use a framework like scrum to help you start thinking that way and to practice building agile principles into your everyday communication and work.
The definition of scrum is based on empiricism and lean thinking. Empiricism says that knowledge comes from experience and that decisions are made based on what is observed. Lean thinking reduces waste and focuses on essentials. It acknowledges that the team doesn't know everything at the start of a project and will evolve through experience. Scrum is structured to help teams naturally adapt to changing conditions and user requirements, with re-prioritization built into the process and short release cycles so your team can constantly learn and improve.
Scrum is structured, it is not entirely rigid. Its execution can be tailored to the needs of any organization. Clean communication, transparency and a dedication to continuous improvement should always remain at the center of whatever framework you choose.
The scrum team
A scrum team is a small and nimble team dedicated to delivering committed product increments. A scrum team's size is typically small, at around 10 people, but it's large enough to complete a substantial amount of work within a sprint. A scrum team needs three specific roles:
product owner
scrum master
the development team - it includes testers, designers, UX specialists, and ops engineers in addition to developers.
The scrum product owner
Product owners are the champions of their product. They are focused on understanding business, customer, and market requirements, then prioritizing the work done by the engineering team accordingly. Effective product owners:
Build and manage the product backlog
Closely partner with the business and the team to ensure everyone understands the work items in the product backlog.
Give the team clear guidance on which features to deliver next.
Decide when to ship the product with a predisposition towards more frequent delivery.
The product owner is not always the product manager. Product owners focus on ensuring the development team delivers the most value to the business. Also, the product owner must be an individual. No development team wants mixed guidance from multiple product owners.
The scrum master
Scrum masters are the champions for scrum within their teams. They coach teams, product owners, and the business on the scrum process, and look for ways to fine-tune their practice of it.
An effective scrum master deeply understands the work being done by the team and can help the team optimize their transparency and delivery flow. He/she schedules the needed resources for sprint planning, standup, sprint review, and the sprint retrospective.
The scrum development team
Scrum teams get 💩 done. they are the champions for sustainable development practices. The most effective scrum teams are tight-knit, co-located, and usually have five to seven members. One way to work out the team size is to use the famous "two pizza rule". The team should be small enough to share two pizzas.
The team members have different skill sets, and cross-train each other so no one person becomes a bottleneck in the delivery of work. Strong teams are self-organizing and approach their projects with a clear 'we' attitude. All members of the team help one another to ensure a successful sprint completion.
The scrum team drives the plan for each sprint. They forecast how much work they believe they can complete over the iteration using their historical velocity as a guide.
Scrum artifacts
Scrum artifacts are important information used by the scrum team that helps define the product and what work to be done to create the product. There are three artifacts in scrum:
Product backlog is the primary list of work that needs to get done and maintained by the product owner or product manager. This is a dynamic list of features, requirements, enhancements, and fixes that acts as the input for the sprint backlog. It is, essentially, the teams "To Do" list. The product backlog is constantly revisited, re-prioritized and maintained by the product owner
Sprint backlog is the list of items, user stories, or bug fixes, selected by the development team for implementation in the current sprint cycle. Before each sprint, in the sprint planning meeting the team chooses which items it will work on for the sprint from the product backlog. The fundamental sprint goal - what the team wants to achieve from the current sprint - cannot be compromised
Increment is the usable end-product from a sprint. It is often referred to as the team's definition of "Done"
Scrum ceremonies or events
The scrum framework includes scrum practices, ceremonies, and meetings that scrum teams perform regularly.
List of all the key ceremonies a scrum team might partake in:
Organize the backlog: Sometimes known as backlog grooming, this event is the responsibility of the product owner. The product owner's main jobs are to drive the product towards its product vision and have a constant pulse on the market and the customer.
Sprint planning: The work to be performed during the current sprint is planned during this meeting by the entire development team. This meeting is led by the scrum master and is where the team decides on the print goal. Specific user stories are then added to the sprint from the product backlog. These stories always align with the goal and are also agreed upon by the scrum team to be feasible to implement during the sprint.
Sprint: A sprint is an actual period when the scrum team works together to finish an increment. Two weeks is a pretty typical length for a sprint, though some teams find a week to be easier to the scope or a month to easier to deliver a valuable increment. During this period, the scope can be re-negotiated between the product owner and the development team if necessary.
Daily scrum or stand up: This is a daily super-short meeting that happens at the same time and place to keep it simple. Many teams try to complete the meeting in 15 minutes, but that's just a guideline. The goal of the daily scrum is for everyone on the team to be on the same page, aligned with the sprint goal, and to get a plan out for the next 24 hours. The stand up is the time to voice any concerns you have with meeting the sprint goal or any blockers.
Sprint review: At the end of the sprint, the team gets together for an informal session to view a demo of, or inspect, the increment. The development team showcases the backlog items that are now 'Done' to stakeholders and teammates for feedback. The product owner can decide whether or not to release the incremnt.
Sprint retrospective: The retrospective is where the team comes together to document and discuss what worked and what didn't work in a sprint, a project, people or relationships, tools, or even for certain ceremonies. The idea is to create a place where the team can focus on what went well and what needs to be improved for the next time.
Scrum values
Five scrum values were added to the scrum guide
Commitment
As scrum teams are small and agile, each team member plays a significant role in the team's success. Therefore, each team member should agree to commit to performing tasks they can complete and not overcommit. There should be frequent communication regarding work progress, often in standups
Courage
Courage for a scrum team is simply the bravery to question the status quo or anything that hampers its ability to succeed. Scrum team members should have the courage, and feel safe enough, to try new things. A scrum team should have the courage and feel safe to be transparent about roadblocks, project progress, delays and so on.
Focus
At the heart of the workflow for scrum team is the sprint, a focused and specified period where the team completes a set amount of work.
Openness
The daily stand-up fosters an openness that allows teams to talk openly about work in progress and blockers.
Respect
The strength of an agile team lies in its collaboration and recognizing that each team member contributes to work in a sprint. They celebrate each other's accomplishments and are respectful of one another
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 team ship better software with fewer headaches.
"With scrum, a product is built in a series of iterations called sprints that break down big, complex projects into bite-sized pieces".
Agile and scrum are not same thing. Agile is a set of principles and scrum is a framework for getting 💩 done.
Sprint planning is a collaborative event where two basic questionnaires are resolved, what work can get done in this sprint and how will the chosen work get done?
It's a collaborative effort between the product owner, scrum master and development team. For any sprint it takes an item in the backlog to "in-progress" and "Done".
Do's and Don'ts
Do:
Make sure the team sets and understands the sprint goal and how success will be measured. This is the key to keeping everyone aligned and moving forward toward a common destination.
Do ensure you have a well-groomed backlog with your priorities and dependencies in order. This can be a big challenge that could derail the process if it's not properly managed.
Ensure you have a good understanding of velocity, and that it reflects things like leave and team meetings.
Do use the sprint planning meeting to flesh out intimate details of the work that needs to get done. Encourage team members to sketch out tasks for all stories, bugs, and tasks that come into the sprint.
Leave out work where you won't be able to get the dependencies done, like work from another team, designs, and legal sign-off.
Finally, once a decision or plan is made, make sure someone captures that information in your project management or collaboration tool
Don't:
Don't pull in too many stories, overestimate velocity, or pull in tasks that can't be completed in the sprint.
Don't forget about quality or technical debt. Make sure to budget time for QA and non-feature work, like bugs and engineering health.
Don't let the team have a fuzzy view of what's in the sprint. Nail it down, and don't focus so much on moving fast rather make sure everyone's moving in the same direction.
Also, don't take on a large amount of unknown or high-risk work. Break down stories that are large or have high uncertainty, and don't be afraid to leave some of that work for the next sprint.
If you hear concerns from the team, whether it's about velocity, low-certainty work, or work they think is bigger than what they estimated, don't ignore it. Address the issue, and recalibrate when necessary.
What is sprint planning?
Sprint planning is an event in the scrum that kicks off the sprint. The purpose of sprint planning is to define what can be delivered in the sprint and how that work will be achieved. Sprint planning is done in collaboration with the whole scrum team.
In scrum, the sprint is an interval where all the work is done. However, before you can leap into action you have to set up the sprint. You need to decide on how long time box is going to be, the sprint goal, and where you're going to start. If done correctly, it also creates an environment where the team is motivated, challenged, and can be successsful. Bad sprint plans can derail the team by setting unrealistic expectations.
The What- The product owner describes the objective of the sprint and what backlog items contribute to the goal. The scrum team decides what can be done in the coming sprint and what they will do during the sprint to make that happen.
The How - The development team plans the work necessary to deliver the sprint goal. Ultimately, the resulting sprint plan is a negotiation between the development team and product owner based on value and effort.
The Who - You cannot do sprint planning without the product owner or the development team. The product owner defines the goal based on the value that they seek. The development team needs to understand how they can or cannot deliver that goal. If either is missing from this event it makes planning the sprint almost impossible.
The Inputs - A great starting point for the sprint plan is the product backlog as it provides a list of stuff that could potentially be part of the current sprint. The team should also look at the existing work done in the increment and have a view to capacity.
The Outputs - The most important outcome for the sprint planning meeting is that the team can describe the goal of the sprint and how it will start working toward that goal.
Setting a time limit for sprint planning
Sprint planning should be constrained no more than two hours for each week of the sprint. This is called "timeboxing", or setting a maximum amount of time for the team to accomplish a task. The scrum master is responsible for making sure the meeting happens the timebox is understood. A timebox is the maximum time allowed; there is no minimum time allowed.
Focus on the outcomes, not the work
During sprint planning, it is easy to get bogged down in the work focusing on which task should come first, who should do it, and long will it take. Scrum is an empirical process, meaning that you can't plan upfront, but rather learn by doing, and then feed that information back into the process.
By adding clear, measurable results to the user story, the outcomes can be measured, and you know when you are done. By getting as much up-front clarity as possible on the work the team is focusing on, everyone gets the transparency needed to get started on the work.
Estimates are required but don't pretend you know more than you do
Sprint planning requires some level of estimation. The team needs to define what can or cannot be done in the sprint: estimated effort vs capacity. Estimation is often confused with commitments. Estimates are by their very nature forecasts based on the knowledge at hand. techniques such as stories points or t-shirt sizing add value to the process by giving the team a different way of looking at the problem.
Good estimates require a trust-based environment where information is given freely, and assumptions are discussed in the pursuit of learning and improvement.
Sprint planning best practices
It is easy to get so bogged down in the details of sprint planning you forgot that the focus of sprint planning is to build just enough plan for the next sprint. A good sprint plan motivates everyone by defining an outcome and a clear plan for success. Instead of building the complete "every minute of the sprint is accounted for" sprint plan, focus on the goal and build enough of a sprint backlog to get started. Next, ensure that the product backlog is ordered to allow the team to pick up work if they delivered on the sprint goal early.
Scrum is a process framework aimed at solving complex problems. Complex problems require an empirical process. Empirical processes are very hard to plan, so don't kid yourself. You can't build the perfect plan. Instead, focus on the outcomes and get going. It does not have to be hard, even if the problem you are solving is.
Ceremonies
What are scrum ceremonies?
Scrum meetings are when the scrum master, product owner, and development team meet to plan work, discuss work in progress, gather feedback and more.
Sprint planning
When practicing scrum, the sprint planning meeting is held at the beginning of the sprint and is where teams identify what can be delivered in the sprint and that work will be achieved. At the end of planning meeting, every scrum members needs to be clear on what can be delivered in the sprint and how the increment can be delivered.
Attendees:
Development team, scrum master, product owner
When:
At the beginning of a sprint
Duration:
Usually around one hour per week of iteration
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 scrum 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
The daily stand-up aka daily scrum - is a short 15 min (or less) daily meeting to discuss progress and identify blockers. Attendees are urged to participate while standing to help keep the meeting short.
Attendees:
Development team, scrum master and product master
When:
Once per day, typically in the morning
Duration:
No more than 15 min. Standing up helps keep the meeting short!
Agile framework:
Scrum and kanban
Purpose:
A daily stand-up is designed to quickly inform everyone of what's going on across the team. It's not a detailed status meeting. The tome should be light and fun, but informative. Have each team member answer 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 yours peers.
Sprint review
The sprint review also called an iteration review, is where the scrum team meets to reveal what was accomplished during the sprint. A development team shows which backlog items are "Done" to stakeholders and teammates.
Attendees:
Development team, scrum master, product owner
When:
At the end of a sprint
Duration:
Typically 45 minutes per week of iteration
Agile framework:
Scrum and kanban. Scrum teams do sprint retrospectives based on a fixed cadence. Kanban teams can benefit from occasional retrospectives too.
Purpose:
A sprint 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 scrum meeting structure. This is the time for the team to celebrate their accomplishments, demonstrate work finished within the iteration, and get immediate feedback from the 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.
Sprint retrospective
A sprint retrospective is a meeting to review what was successful during the sprint and what can be improved upon. Agile teams can specifically review team dynamics, processes, and tools, then create plans to improve the way the team works.
Attendees:
Development team, scrum master, product owner
When:
At the end of a sprint
Duration:
Typically 45 min per week of iteration
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.
Backlogs
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.
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 requirement. 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.
Start with the two "R"s
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.
Let's take a look at the roadmap for a fictitious product called Teams in space.
Since the teams in space website is the first initiative in the roadmap, we'll want to break down that initiative into epics and user stories for each those epics.
The product owner organizes each of the user stories into a single list for the development team. The product owner may choose to deliver a complete epic 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
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.
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. 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 begin 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 the changes to a minimum as they disrupt the development team and affect the 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 do product backlogs 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.
Sprint Review
Sprint reviews are not retrospectives. A sprint review is about demonstrating the hard work of the entire team: designers, developers, and the product owner.
Step 1: Define 'done'
Crossing the finish line and completing work requires good planning, a clear definition of 'done' and focused execution. To have a successful sprint review and sprint, teams need to do a little more than planning. They need to develop a clear culture of how to deliver work as well as what it means to be 'done'.
A culture of delivery
Effective teams bring clear processes and development culture to 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 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'?
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 process.
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.
Step 2: Celebrate the team
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
Step 3: Reach across geographies
Companies with distributed teams have special challenges around scaling agile ceremonies across geographies.
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.
Standups
What is a stand-up in scrum?
The daily stand-up is a short, daily meeting to discuss progress and identify blockers. The reason it's called a "stand-up" is because if attendees participate while standing, the meeting should be kept short.
For software teams, a stand-up is like a sports team's huddle. The huddle is strategic: it keeps the team informed, connected, and calibrated throughout the game. It's even commonly known as the daily scrum, and reinforces "we" to keep everyone aware of the team's landscape and progress.
A stand-up is a daily meeting that involves the core team: product owners, developers, and the scrum master.
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. The daily reinforcement of sharing individual successes and plans keeps everyone excited about the team's overall contribution to the organization.
Stand-ups for distributed teams
For distributed teams, each member has to join a video stand-up on their computer. With everyone in their own dedicated space and on the same video call, the team has leveled the playing field. All team members can see, hear, and experience the same information at the same time.
Tips for remote stand-ups:
Make team members visual - Teams use the "Brady Bunch" view on team video calls. This gives visibility to all members so you can connect with more than just the person that's talking.
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 comment on their work board to share updates as they come online.
Scrum master
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 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
Standups - Facilitate daily standups as needed
Iteration/sprint planning meetings - Protect the team from over-committing and scope creep. Aid in estimation and sub-task creation.
Sprint reviews - Participate in the meeting and capture feedback
Retrospectives - Note areas for improvement and action for future sprints.
Board administration - Work as the administrator of the scrum board. Ensure that cards are up to date and the scrum tool.
1 on 1s - Meet individually with team memebers and stakeholders as needed. Iron out team disagreements about process and work styles.
Internal Consulting - Scrum master should be prepared to consult with team members and internal stakeholders on how best to work with the scrum team.
Reporting - Regular analysis of burndown chats and other portfolio planning tools to understand what gets built and at what cadence.
Blockers - 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 master vs. product manager
The more involved 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 scrum master's non-technical 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.
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 product manager sets and tracks timeframes and milestones, progress reports, and coordinates team communication.
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.
Retrospectives
A retrospective is anytime your team reflects on the past to improve the future.
"At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly"
The agile manifesto makes it clear: To best live the agile values, teams meet regularly to check in and make adjustments. Most commonly, development teams apply this principle by hosting regular retrospective meetings.
At face value, this is what a retro is all about: Working with real people to make changes and improvements.
The purpose of the retrospective meeting is to:
Evaluate how the last sprint, iteration, or work item went, specifically around the team dynamic, processes and tools.
Articulate and stack rank the items that went well, and those items that did not.
Create and implement a plan for improving the way team does work.
How to run your first retrospective
The when:
For agile teams working in the traditional two-week sprint, the retrospective should take place at the end of every sprint. For teams running a more kanban-esque style of work, a monthly or quarterly retrospective may make more sense.
The who:
Every team member should attend the retrospective, with a facilitator leading the discussion. The facilitator can be the scrum master, product owner, or it can rotate throughout the team.
The what:
Create a short list of things that worked well and things that could be improved.
Prioritize this list by importance as a team
Discuss ways and tactics to improve the top two items on the "room for improvement" list
Create an action plan
Be disciplined about executing.
Distributed scrum
What is a distributed scrum team?
A distributed scrum team is just that -- a scrum team that is either fully or partially remote. 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.
Benefits
Wider pool of available talent can increase the skill sets of teams.
Teams across geographies that allows for 24-hour workday
Challenges
Agile development was originally intended for teams physically located in the same office. The Agile Manifesto, written in 2001, stated that "the most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
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 track progress and quality. Tools should be:
Be accessible to all team members
Enable collaboration, sharing, and notifications to team members
A collection of relevant, engaging information
Roles
What are three scrum roles?
Scrum has three roles: product owner, scrum master, and development team members.
Scrum roles vs. job titles
These three scrum roles describe the key responsibilities for those on the scrum team. They aren't job titles. This means that any job title, even your existing ones, can perform one of the roles. This allows teams to take responsibility for how they organize and to keep improving themselves.
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 is doesn't do is provide a one-size-fits-all model for teams to work within.
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 includes 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.
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
Product owner: Setting clear direction
Scrum product owners understand the customer and business requirements, then create and manage the product backlog based on those requirements. Since agile teams are, by design, flexible and responsive, it is the responsibility of the product owner to ensure that they are delivering the most value.
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.
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 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 server 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.
Get Started with agile scrum roles
If you have a lot of great skills for delivering customer value and that is what excites you, then you should be a scrum development team member.
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.
If you want to help team work effectively together and also want to change the world with scrum and agile, then scrum master role is for you.
Scrum of Scrums
What is scrum of scrums?
Scrum of scrums is a scaled agile technique that offers a way to connect multiple teams who need to work together to deliver complex solutions.
It helps teams develop and deliver complex products through transparency, inspection, and adaptation at scale. It's particularly successful when all high-performing scrum team members work towards a common goal, have trust, respect and are completely aligned.
The larger a team size, the greater lines of communication between team members, making it harder to create trust and a common purpose.
The purpose of Scrum of Scrums
A scrum of scrums is a virtual team consisting of delegates with embedded links to the originating delivery teams. The aim is to coordinate smaller, independent teams. Teams who apply scrum of scrums not only coordinate delivery but ensure a fully integrated product at the end of every sprint. Therefore scrum of scrums acts as a release team that delivers value to customers.
Conclusion and considerations
Scrum of scrums is widely used and a key way to scale scrum.
When teams are ready, here are some considerations that may be useful:
Keep the scaled daily scrum meeting to 15 minutes, mirroring your team daily scrum
Conduct the scaled daily scrum for 15 minutes after the last team daily scrum
Establish a working agreement for the scrum of scrums
Agree on the collective and individual definition of completed, and of course share it!
Establish a routine or agenda to keep the scaled daily scrum focused
Start tracking the number of days you're blocked by impediments
Track how many scaled daily scrums were started and finished on time
Focus on delivering stories that have dependencies first to reduce risk and enable other teams.
Track and visualize the days until the demo meeting
Agile scrum artifacts
What are agile scrum artifacts?
Agile scrum artifacts are information that a scrum team and stakeholders use to detail the product being developed, actions to produce it, and the actions performed during the project. These artifacts provide metadata points that give insight into the performance of a sprint. They are essential tools for every scrum team since they enable core scrum attributes of transparency, inspection, and adaption.
Artifacts are created during the main activities of a scrum
Plan work and future goals
Create tasks to achieve these goals
Organize tasks into sprints based on dependency and priority
Execute the tasks
Review and analyze results to compare to the goals
Repeat these steps
The main artifacts of agile scrum
Product backlog
It is a list of new features enhancements, bug fixes, tasks, or work requirements needed to build a product. It's compiled from input sources like customer support, competitor analysis, market demands, and general business analysis.
Sprint backlog
The sprint backlog is a set of product backlog tasks that have been promoted to be developed during the next product increment. Sprint backlogs are created by the development teams to plan deliverables for future increments and detail the work required to create the increment
Scrum metrics
Scrum metrics are specific data points that scrum teams track and use to improve efficiency and effectiveness. Scrum teams use metrics to inform decision-making and become more efficient in planning and execution, as well as set target goals and improvement plans.
courtesy: Atlassian