Leading IT Transformation – Workshop 22 (Implementing Scrum)
The Appleton Greene Corporate Training Program (CTP) for Leading IT Transformation is provided by Ms. Drabenstadt MBA BBA Certified Learning Provider (CLP). Program Specifications: Monthly cost USD$2,500.00; Monthly Workshops 6 hours; Monthly Support 4 hours; Program Duration 24 months; Program orders subject to ongoing availability.
If you would like to view the Client Information Hub (CIH) for this program, please Click Here
Learning Provider Profile
Ms. Drabenstadt is a Certified Learning Provider (CLP) at Appleton Greene and she has experience in Information Technology, Information Governance, Compliance and Audit. She has achieved an MBA, and BBA. She has industry experience within the following sectors: Technology; Insurance and Financial Services. She has had commercial experience within the following countries: United States of America, Canada, Australia, India, Trinidad, and Jamaica. Her program will initially be available in the following cities: Madison WI; Minneapolis MN; Chicago IL; Atlanta GA and Denver CO. Her personal achievements include: Developed Trusted IT-Business Relationship; Delivered Increased Business Value/Time; Decreased IT Costs; Re-tooled IT Staff; Increased IT Employee Morale. Her service skills incorporate: IT transformation leadership; process improvement; change management; program management and information governance.
MOST Analysis
Mission Statement
Scrum is a framework for implementing an agile approach in an organization. The agile method focuses on quick response to change, short sprints of work, and incremental growth to ensure increased productivity. The agile method is characterized by iterative developments and Scrum is the ideal framework for organizations seeking to adopt an agile approach. Scrum helps in a project’s development by taking up small iterations that are repeated for every task until the final product is ready to be delivered. There are specific roles, events, and rules within the Scrum framework that must be followed by every member of the Scrum Team to ensure the success of Scrum. Implementation of Scrum requires a Scrum Team, which is managed by the Scrum Master. The role of the Scrum Master is to remove roadblocks and ensure compliance with the Scrum rules. There is also a Product Owner who is responsible for defining the requirements of the project, helping the team in the development of the project each day, and validating the deliveries. The Product Owner interacts with all the stakeholders of the project. The project is executed in short sprints and at the end of each sprint, an incremental version of the product is delivered until the final product or outcome is achieved. The project is distributed into sprints during the sprint planning meeting. There are daily meetings to review the status of activities and sprint review meetings to assess the results and deliveries at the end of each sprint, to see if they are within the expectation of the Product Owner.
Objectives
01. Define your Scrum Team: departmental SWOT analysis; strategy research & development. Time Allocated: 1 Month
02. Scrum Master: departmental SWOT analysis; strategy research & development. Time Allocated: 1 Month
03. Product Owner: departmental SWOT analysis; strategy research & development. Time Allocated: 1 Month
04. Initiation Phase: departmental SWOT analysis; strategy research & development. Time Allocated: 1 Month
05. Planning & Estimates Phase: departmental SWOT analysis; strategy research & development. Time Allocated: 1 Month
06. Sprint Planning Meeting: departmental SWOT analysis; strategy research & development. Time Allocated: 1 Month
Strategies
01. Define your Scrum Team: Each individual department head to undertake departmental SWOT analysis; strategy research & development.
02. Scrum Master: Each individual department head to undertake departmental SWOT analysis; strategy research & development.
03. Product Owner: Each individual department head to undertake departmental SWOT analysis; strategy research & development.
04. Initiation Phase: Each individual department head to undertake departmental SWOT analysis; strategy research & development.
05. Planning & Estimates Phase: Each individual department head to undertake departmental SWOT analysis; strategy research & development.
06. Sprint Planning Meeting: Each individual department head to undertake departmental SWOT analysis; strategy research & development.
Tasks
01. Create a task on your calendar, to be completed within the next month, to analyze Define your Scrum Team.
02. Create a task on your calendar, to be completed within the next month, to analyze Scrum Master.
03. Create a task on your calendar, to be completed within the next month, to analyze Product Owner.
04. Create a task on your calendar, to be completed within the next month, to analyze Initiation Phase.
05. Create a task on your calendar, to be completed within the next month, to analyze Planning & Estimates Phase.
06. Create a task on your calendar, to be completed within the next month, to analyze Sprint Planning Meeting.
Introduction
Scrum challenges traditional software development management methods by eliminating micromanagement and promoting developer accountability. The outcome is a software product that meets requirements, includes all desired features, and performs as expected. In this workshop, we will explore the Scrum development approach, its framework, and how its elements synergistically contribute to software development.
The Essence of Scrum
Scrum is a set of values, principles, and practices that are lightweight yet immensely powerful. It relies on cross-functional teams to deliver products and services in short cycles, enabling several benefits:
• Swift feedback
• Increased innovation pace
• Continuous improvement
• Agile adaptation to change
• Enhanced customer satisfaction
• Accelerated idea-to-delivery timeframe
What is Scrum development?
Source: www.softwaretestinghelp.com
Scrum is an Agile method of managing software development. It allows the development team to work freely to find solutions to issues without relying on conventional management techniques. Instead, it depends on everyone working together as a team and contributing to the discussion of the current problem.
Scrum borrows its name from the game of rugby. A scrum is a player formation in which players link arms and lower their heads in order to push into a comparable group of opponents. The game starts when the rugby ball is hurled into the scrum. Scrum development is built on the idea that no one player is in control of the course of the game, which is how rugby is played.
The majority of software development models are built on the hierarchy of the team and forward movement. The reporting and responsibility levels in this approach are progressively increased from the lowest level all the way to management. The lowest-level employees carry out their jobs and responsibilities with a concentration on finishing by a particular deadline. Making sure the task progresses and reporting on it to top management is the responsibility of management. To provide a product by a specific date, a predictable workflow and chain of command are followed.
Scrum takes a distinct approach to software development by eschewing the conventional technique and fostering an environment of agile development. The development team is emancipated from managerial scrutiny and given responsibility of the development process in the Scrum model of project development. As a result, the team is better equipped to address issues as they arise and establish its own timetable for completing the task at hand.
What is the Scrum glossary?
The Scrum glossary comprises terms that serve as concise descriptions for various elements of Scrum development. Some terms, such as “product backlog” and “sprints,” are considered mandatory, while others are included due to their common usage in conjunction with Scrum elements. Examples of glossary terms include the “burndown chart,” which visualizes the remaining work in a backlog, and the “daily scrum,” which outlines the plan for the next day’s work during a sprint period. These glossary terms save time and promote understanding among team members by providing a shorthand method of communication.
Glossary terms are fundamental to using Scrum as a model for software development. They are a type of software shorthand that may be used both orally and in writing to explain what is happening to the reader in one or two words as opposed to several. Utilizing the glossary’s terms can help the team communicate more effectively and save time.
The basics of Scrum development
The founders of Scrum believed that the conventional approaches to software development were oppressive and unsuitable for producing high-quality software. Management’s excessive control over the development team might impede their ability to produce the best product, slow down the production process, and raise production costs.
Scrum development provides everyone in development authority over their development roles and liberates the development team from the management structure. The development team divides up into various groups that each concentrate on a certain task, and then they get together to talk about integration and progress with other groups that are working on different parts of the product. Teams can be more creative, more adaptable, and more focused on producing high-quality software.
Framework of Scrum development
Source: www.startinfinity.com
Scrum development’s framework reduces the role of management in the daily activities of a software development team and lets the team make its own decisions as to the tasks of a set timeframe known as a sprint. There are a variety of processes and techniques that can be employed, and used as needed, within the framework instead of being required by management.
A Scrum process framework begins with the sprint review, moves to the sprint retrospective and then the evaluation of the product backlog and prioritized features in the product. Work progresses along the framework and the sprint is reviewed regularly to make sure goals are being met and the product will be ready on the planned day of release. Here is a breakdown of the framework:
Main components of Scrum
Scrum’s artifacts define the overall process of development. They include:
• Primary Artifact: This is the product being developed.
• Product Backlog: A backlog is created at the beginning of the development process.
• Sprint and Release Burndown Charts: The sprint and release burndown charts track how much work is remaining in a sprint that leads up to the release of the product.
Values and pillars of Scrum
When all of the values are respected and embodied by the Scrum team, the Scrum pillars also come into existence.
Source: www.zeolearn.com
The values of Scrum include:
• Commitment
• Courage
• Focus
• Openness
• Respect
The pillars of Scrum include:
Source: www.resources.scrumalliance.org
• Transparency
• Inspection
• Adaptation
Scrum development is based on the idea that everyone should put up their best effort and give the project their all. Teams are no longer subject to managerial control, thus everyone must take responsibility for the tasks specified by the sprint. Everyone should agree to concentrate on the task at hand, be honest about any difficulties they may encounter, and accept one another as competent, self-sufficient persons.
Fitting roles into Scrum development
Software development personnel frequently have conventional job titles that specify their duties. The traditional titles of product owner, development team, scrum team, and scrum master do not, however, correspond to the Scrum titles. With a little expectation-shifting, each conventional function may easily fit into the Scrum structure.
Given that Scrum teams are made up of a few developers that collaborate on the same project, a former team leader can easily transition into the job of Scrum master. Some people might discover that they can switch between various Scrum development titles throughout a sprint.
Creating a Scrum sprint
Source: www.visual-paradigm.com
The foundation of the Scrum development model is the sprint. The entire team gathers for a sprint planning meeting to determine what work needs to be completed during the sprint. The backlog is what we refer to as. The work that has to be done is conceived of as a backlog that needs to be cleared before proceeding onto the next stage of the project, rather than as a to-do list.
A sprint might range from a few weeks to a month, depending on how much time is required. The goal of a sprint is to complete the job in the lowest amount of time while utilizing all available staff effort. To meet targets, Scrum wants to limit sprints to one month. However, being adaptable and agile is at the heart of Scrum. A new sprint must be made if more time is required.
The product backlog is created with a goal for each sprint in mind, although this goal is not fixed. The team is always free to modify the sprint or the product backlog as needed.
The scrum master sets a timebox for the sprint. The scrum master’s duties include keeping the box up to date, reminding the development team how much longer the sprint is, and ensuring that the team adheres to the best practices and procedures established at the start of the sprint. The product owner is updated on the progress of the development team through communication with the scrum master as well.
Elements of a sprint
A sprint’s objective is to finish a usable product that has the potential to be released after completion. Whether there are one or many sprints within a development cycle, the duration of each sprint is the same. Each subsequent sprint will also last two weeks if the initial sprint lasts two weeks. The next sprint starts as soon as the previous one concludes.
A sprint is made up of the sprint planning, which can take up to eight hours, daily scrums, or reviews of the work completed and that which remains to be done, the actual work, the review at the conclusion of the sprint, and the sprint retrospective, which takes a look back at the work completed during the sprint.
Once a sprint is started, a set of rules must be followed in order for it to succeed. These laws comprise:
• No changes are allowed if they put the goal of the sprint in danger.
• Quality goals cannot be lowered.
• Project scope can be clarified and renegotiated between the development team and product owner as the work progresses and information is uncovered.
A project is a sprint, and a sprint is a project. Each sprint, however, has a distinct emphasis that it must adhere to from beginning to end. Only one calendar month may elapse between sprints. A extended time frame is thought to make the sprint groups lose focus and put their work at risk of falling behind. After the initial sprint, if another is required, the team can start a new sprint meeting to assess the results and decide what steps should be taken to continue the product’s development. The product owner and the scrum master communicate regularly on the status of the product as well as how everything is progressing.
Top Industries That Are Adopting Scrum
The Agile Scrum methodology has had a significant impact on the software development field, enabling teams to adopt an agile approach for project completion. Now, industries beyond software development are also reaping the benefits of Agile Scrum.
Implementing a Scrum-based project management approach fosters enhanced teamwork, efficiency, and effectiveness in achieving shared goals. This strategy consistently yields improvements in organization, collaboration, and communication, resulting in higher-quality deliverables and improved team morale.
A key component of the Agile Scrum process is the daily team meeting known as a “scrum,” which ensures that all team members remain focused on top priorities. While traditionally associated with software development companies, other organizations are increasingly embracing the Scrum approach to project management to avail its advantages.
Industry Sectors Currently Benefiting from an Agile Scrum Approach
Most companies are faced with hardships or difficult tasks at some point in time. By distributing the work among different members in a collaborative group setting, the task tends to become much simpler.
Source: www.dtraining.co.nz
The Agile Scrum approach has gained popularity across various industry sectors due to its ability to enhance collaboration, adaptability, and productivity. While its principles and practices can be applied to almost any domain, there are some industry sectors that have particularly embraced the Agile Scrum methodology. Here are a few examples:
1. Software Development: The software industry has been one of the earliest and most prominent adopters of Agile Scrum. Agile methodologies such as Scrum enable software development teams to deliver high-quality products in shorter iterations, respond to changing requirements, and improve customer satisfaction.
2. Construction: Major construction projects usually carry high capital and regulation risks and tough schedules. Over the past few years, a number of companies have turned towards Agile methodologies to plan, design and execute their projects. Agile has been particularly useful for the companies to make real-time decisions, ensure effective collaboration and communication and aligning all the milestones towards the final goal to be accomplished.
3. Information Technology (IT) Services: IT service providers, including consulting firms, managed service providers, and technology companies, have increasingly adopted Agile Scrum to improve project management, collaboration, and service delivery. Agile methods help them meet clients’ evolving needs and deliver value-driven solutions.
4. Automotive: Some vehicle manufacturers have begun to adopt a scrum approach to project management as well. Because the traditional auto industry tends to operate in slower development cycles, an agile scrum approach offers an opportunity to speed up the pace of innovation. An increasing number of companies and industries are relying on an agile scrum approach to keep projects moving in an organized and efficient manner.
5. Marketing and Advertising: Agile Scrum is gaining traction in marketing and advertising agencies. The dynamic nature of these industries often requires quick turnarounds, continuous improvement, and flexibility. Scrum helps teams manage campaigns, creative projects, and content production by promoting transparency, iterative workflows, and effective communication.
An example is of Teradata Applications, which is in the business of selling software for the purpose of supporting marketing. The company made use of Agile methodologies to automate workflow and approval processes. They credit Scrum Agile techniques for the improved communications in within the project which has helped them enhance their processes.
6. Event planning: In the past few years, Agile Scrum methodology has made life much easier for event planning firms. Its ability to make real-time changes based on the feedback given and a robust iterative framework makes Agile a tailor-made solution for event planning companies.
Redgate was not satisfied with its rigid approach which made it difficult to respond to any change in the requirements. This led to uncalled for stress at their work. Adopting Agile gave them the freedom to implement and execute their projects with the much-needed agility. This has helped the company in meeting tight deadlines and ensuring the utmost satisfaction of the end customer.
7. Product Development: Agile Scrum is widely employed in product development across various sectors, including manufacturing, consumer goods, and automotive industries. It enables cross-functional teams to collaborate efficiently, prioritize features based on customer feedback, and deliver products faster to market.
Wikispeed came up with a functional prototype of a 100 mpg car in just three months using Agile radical management methods. In comparison, an orthodox manufacturing process is a long process spanning over multiple years. With the help of Agile, the team at Wikispeed has been able to bring innovation at a much faster pace in an industry where development cycles can go on for decades. Using one-week-long ‘sprints’ under the Agile model has worked wonders for Wikispeed and its project.
8. Financial Services: Agile Scrum has found applications in the financial services industry, including banking, insurance, and fintech. It helps teams streamline complex processes, develop innovative solutions, and respond to changing regulatory requirements swiftly.
Principal Financial Group, an insurance provider and retirement planning firm, started using agile methodologies to ensure that business and IT unit leaders come together on the requirements of the feature in sprints which are two weeks long. In case any feature breaks down, it can be retrieved without the need of taking the entire app back. The entire staff of the company has been very receptive to the adoption of Scrum Agile.
9. Healthcare: Agile Scrum has been adopted in healthcare organizations to improve project management, software development, and quality improvement initiatives. It facilitates collaboration among interdisciplinary teams, enhances patient-centric care, and supports the development of digital health solutions.
10. Education and Training: Agile Scrum has been employed in educational institutions and training organizations to manage curriculum development, instructional design, and e-learning projects. It allows for iterative content creation, continuous feedback, and adaptive learning experiences.
11. Military: The U.S. government, particularly various military groups, is another organization that relies on scrum to successfully operate. A scrum approach is often used when deploying ships or keeping different units on the same track. When good communication that is efficient and effective is a life and death matter, scrum proves to offer a helpful framework.
It’s important to note that Agile Scrum’s benefits are not limited to these sectors alone. Its principles of collaboration, adaptability, and customer-centricity can be applied in diverse industries to improve project outcomes and organizational agility.
The next time you use a smartphone app, or go shopping for a new car, you can bet that scrum project management may have been implemented to create your device. Scrum can be beneficial to any organization or company willing to make the move from a more traditional approach to project management (often top-down), to a more collaborative, cross-functional so-called “agile” process.
Executive Summary
Chapter 1: Define your Scrum Team
Every Scrum team should ideally consist of one Scrum Master, one product owner, and a small group of individuals the Scrum Guide refers to as developers. Developers (team members) are the people who are working on the product on a daily basis.
On a Scrum team, everyone collaborates to deliver the body of work that everyone has agreed to finish in a sprint.
As a result, agile teams frequently exhibit a strong sense of unity and a sense that “we’re all in this together.”
The Scrum Team Role
A product owner, a Scrum Master, and many developers (team members) make up a Scrum team. All actions pertaining to the product are under the purview of the Scrum team.
According to Scrum, every individual working on a project is a developer (or team member). Each iteration, the developers are responsible for producing a useable increment, or a portion of functionality.
People with traditional software job titles (programmer, designer, tester, architect, etc.) are sometimes found on agile teams in a Scrum context. However, regardless of their official title, everyone in the team collaborates to complete the set of tasks they have all agreed to perform during the sprint under Scrum. As a result, even if some people have specialized abilities, they might occasionally work outside their field as needed.
Recommended Scrum Team Size
How big should a Scrum team (or any other agile team) be? Five to nine people, including the product owner and scrum master, make up the ideal Scrum team (the Scrum Guide specifies 10 or less).
A Scrum team should be the right size such that there are enough people with complementary abilities to finish user stories independently but not so many that communication becomes challenging.
Scrum teams are small, why? Smaller teams are better able to establish and maintain connections through team building, which helps them develop into cohesive, high-performing teams rather than just “groups of people” working together.
Responsibilities of a Scrum Team
Teams working in a Scrum framework share a common set of responsibilities:
• Scrum teams are dedicated to iteratively and progressively delivering the product to the client.
• Each sprint, developers are responsible for providing a usable increment of product value.
A well-designed team structure emphasizes the idea that all teams are jointly responsible for the project’s success. Additionally, it gives each team distinct signs of their specific accountabilities.
Defining your Scrum Team is important in Scrum for several reasons:
1. Roles and Responsibilities: By clearly defining the Scrum Team, including the Product Owner, Scrum Master, and Development Team, each member understands their specific role and responsibilities within the framework. This clarity helps to establish effective collaboration, decision-making, and accountability.
2. Collaboration and Synergy: A well-defined Scrum Team promotes collaboration and synergy among its members. When everyone understands their roles and responsibilities, they can work together effectively, leveraging their individual strengths and expertise to achieve the best possible outcomes.
3. Efficient Communication: Defining the Scrum Team facilitates efficient communication within the team. Each member knows who to collaborate with, who to seek guidance from, and who to provide updates or seek feedback. This clarity reduces miscommunication and streamlines information flow.
4. Autonomy and Empowerment: A defined Scrum Team enjoys autonomy and empowerment. Each member has the authority and freedom to make decisions within their respective roles, leading to increased ownership, motivation, and engagement. This empowerment fosters a sense of shared responsibility and commitment to achieving the sprint goals.
5. Cross-Functionality and Skill Utilization: The Scrum Team should be cross-functional, meaning it possesses all the necessary skills to deliver a potentially shippable product increment. Defining the Scrum Team allows for deliberate selection of team members with diverse skill sets, ensuring the availability of the right expertise to tackle various aspects of the product development.
6. Focus and Alignment: A defined Scrum Team helps maintain focus and alignment throughout the project. Each member understands the project’s goals, objectives, and priorities, which promotes a shared vision and minimizes distractions. This focus allows the team to work cohesively towards delivering valuable increments of the product.
7. Continuous Improvement: Defining the Scrum Team enables continuous improvement efforts. The team can reflect on their performance, identify areas of improvement, and take collective action to enhance their collaboration, processes, and outcomes. Having a well-defined team allows for targeted improvements and better tracking of progress.
In summary, defining your Scrum Team is important as it establishes clear roles and responsibilities, promotes collaboration and synergy, facilitates efficient communication, empowers team members, leverages cross-functional skills, ensures focus and alignment, and supports continuous improvement. A well-defined team sets the stage for effective Scrum implementation and enhances the team’s ability to deliver high-quality products.
Chapter 2: Scrum Master
The Scrum Master is in charge of implementing Scrum. In order to serve both the Scrum Team and the greater business, they accomplish this by assisting everyone in understanding Scrum philosophy and practice.
A Scrum Master is much more than this, though. There are many facets and layers to the Scrum Master’s job. Scrum Masters need soft skills in order to coach and guide members of the Scrum Team as well as other members of the company, in addition to raising awareness of Scrum and promoting increased agility. Scrum Masters are responsible for assisting their teams in succeeding, and this frequently entails providing them with group or one-on-one support. They might lead exercises, provide direction, or assist others in coming to their own conclusions.
Since they assist the Scrum Team in continuously improving how they collaborate to produce value, the Scrum Master is ultimately responsible for the effectiveness of the Scrum Team.
Source: www.miro.medium.com
What does a Scrum Master do?
As noted below, Scrum Masters use their special skill set to do a variety of crucial tasks that benefit the Scrum Team and the enterprise.
The Scrum Master:
Helps the Scrum Team:
• By coaching the team members in self-management and cross-functionality
• Focus on creating high-value Increments that meet the Definition of Done
• Influence the removal of impediments to the Scrum Team’s progress
• Ensure that all Scrum events take place and are positive, productive, and kept within the timebox.
Helps the Product Owner:
• Find techniques for effective Product Goal definition and Product Backlog management
• Provide ways for the Scrum Team to understand the need for clear and concise Product Backlog items
• Establish empirical product planning for a complex environment
• Facilitate stakeholder collaboration as requested or needed
Supports the Organization:
• By Leading, training and coaching them in their Scrum adoption
• By helping employees and stakeholders understand and instill an empirical approach for complex work
• Remove barriers between stakeholders and Scrum Teams
Scrum Master Stances
Source: www.scrum.org
Depending on the circumstance or difficulty the team is experiencing, the Scrum Master must wear a variety of hats in order to succeed. The whitepaper The 8 Stances of a Scrum Master by Barry Overeem describes these hats, which are also known as stances. Depending on the circumstance, a Scrum Master may operate as a Servant Leader, Facilitator, Coach, Manager, Mentor, Teacher, Impediment Remover, or Change Agent in any particular setting. Examples include coaching a new developer who needs advice on how to work with their new team, facilitating a new activity to help the Scrum Team run their Sprint Retrospective, and teaching team members a new technique they learned to handle conflicts with the group. The Scrum Master may also take the teacher’s role. These are only a few of the components that make up the Scrum Master’s multi-layered structure.
Chapter 3: Product Owner
A Product Owner is responsible for increasing the value of the final product that the Scrum Team produces. The methods used here can differ greatly amongst organizations, Scrum Teams, and people.
The Product Owner, a member of the Scrum Team, clarifies to the group the vision and purpose of a product. In order to provide value to all stakeholders, including those within their organization and all users inside and outside of it, every work is derived from and prioritized based on the Product Goal. Value is identified, measured, and maximized by product owners over the whole lifecycle of the product.
What does a Product Owner do?
Effective management of the product backlog is the responsibility of the product owner and includes:
• Developing and explicitly communicating the Product Goal
• Creating and clearly communicating Product Backlog Items
• Ordering Product Backlog Items
• Ensuring that the Product Backlog is transparent, visible and understood
The Product Owner can handle this task themselves or assign it to other members of the Scrum Team. No matter who completes the task, the Product Owner is still responsible for its completion and for the value it provides.
Beyond simply managing the product backlog, the Product Owner must gain the trust of the entire company in order to have the backing they require for their choices. The success of a Product Owner depends on this. These choices must be openly disclosed in the Product Backlog and in the work increments shared at the Sprint Review.
Keep in mind that the Product Owner is an individual, not a group. In the Product Backlog, they also represent the needs of numerous stakeholders. If someone within the business wishes to alter the Product Backlog, they should talk to the Product Owner and make an effort to persuade them. The Product Owner, however, ultimately makes the choice. Customer reviews of the product should be provided to the product owner.
Product Owner Stances
Source: www.scrum.org
To reach their ultimate objective of maximizing value, the Product Owner can adopt a number of preferred postures. The Visionary, Collaborator, Customer Representative, Decision Maker, Experimenter, and Influencer are some of these stances. For instance, the Product Owner occasionally adopts the role of the Visionary when outlining the product vision, strategy, and business goals and objectives for all parties involved; they take on the role of the Collaborator when helping the Scrum Team define goals; or they assume the role of the Decision Maker when making various decisions on a daily basis.
Additionally, the roles and responsibilities of the product owner are frequently misunderstood. Examples of these patterns within organizations include the product owner being seen as the story writer, project manager, subject matter expert, clerk, gatekeeper, or manager.
Chapter 4: Initiation Phase
As it lays the groundwork for the remainder of the project, the initiation phase is one of the most important phases of the Scrum process.
The team will develop the project’s vision at this phase, essentially creating a roadmap containing the key aims, deliverables, and objectives. They will also determine the project backlog’s epics, identify all stakeholders, and assign team members to each role.
Product epics, which are features that will be incorporated during development, are listed in the product backlog in priority order. These are produced by a product owner based on the client’s requirements and the project’s vision, and they are often formatted as follows:
As a/the [user role], I want to [product capability] so that [user benefit].
Here are a few examples of product epics:
A website: I want to enroll in this coaching program as soon as possible since I’m an ambitious entrepreneur and don’t want to spend more than five minutes filling out a registration form.
For a media launch event, I want to film and document first-hand, thrilling interactions with the just unveiled product range in order to create original content for my blog.
The team will be prepared to move on to the following phase once all the procedures associated with this phase have been finished.
The Six Processes
Source: www.pbs.twimg.com
Six processes are included in the initiate phase of a Scrum project and they address the particular activities and flow. It’s important to remember that the processes aren’t always carried out simultaneously or separately. Depending on the particular needs of each project, combining various methods could occasionally be more appropriate.
Create Project Vision
The Project Vision Statement, which will act as motivation and a point of focus for the whole project, is created after a review of the Project Business Case. The problem, not the solution, should be the main focus of a project’s vision. The Project Vision Statement should not be too specific and should leave room for flexibility. The Product Owner, who represents the Voice of the Customer during the Create Project Vision process, is in charge of maximizing the project’s business value.
Identify Scrum Master and Stakeholder(s)
Stakeholders and the Scrum Master are chosen based on specific Selection Criteria. The “servant leader” and facilitator known as a “Scrum Master” makes sure that the Scrum Team operates in a way that promotes effective project completion. Customers, users, and sponsors are among the stakeholders who frequently communicate with the Scrum Core Team and have an impact on the project throughout the product development cycle.
Form Scrum Team
Members of the Scrum Team are named. While the Scrum Master and Product Owner frequently work together to choose team members, the Product Owner is typically in charge of this task. A team of individuals known as the Scrum Team is in charge of comprehending the business requirements laid out by the Product Owner, estimating User Stories, and producing the project deliverables. The amount of work to commit to during a Sprint is decided by the team, along with the most effective method of completion.
Develop Epic(s)
The Prioritized Product Backlog’s Epics, which are large, unfinished User Stories, are developed based on the project’s vision statement. User Group Meetings could be held to talk about pertinent Epics. In the early stages of a project, when the majority of User Stories are high-level functionalities and product descriptions and requirements are loosely specified, epics are developed. These Epics are divided into smaller, more detailed User Stories once they are added to the Prioritized Product Backlog for completion in a subsequent Sprint. These shorter User Stories typically consist of functionalities that can be finished in a Sprint and are short, simple, and easy to implement.
Create Prioritized Product Backlog
To create a Prioritized Product Backlog for the project, epics are improved, expanded upon, and then prioritized. A prioritized list of business and project needs presented in the form of epics is created by the product owner and included in the Prioritized Product Backlog. Three main criteria make up the Prioritized Product Backlog: value, risk or uncertainty, and dependencies. This approach also establishes the Done Criteria, a set of guidelines that apply to all User Stories. Unambiguous requirements are eliminated by a precise definition of “Done,” which also aids the team in maintaining required quality standards. When the Product Owner approves a User Story, based on the Done Criteria and the specific User Story Acceptance Criteria, the User Story is said to be “done.”
Conduct Release Planning
In order to create a Release Planning Schedule, which is essentially a schedule for phased deployment that can be shared with the project stakeholders, the Scrum Core Team reviews the User Stories in the Prioritized Product Backlog. The Length of Sprint for the project is decided by the Product Owner and the Scrum Team, and it frequently stays the same throughout the project. However, if the Product Owner and Scrum Team determine that a change is required or appropriate, it may occur.
The six initiate phase methods should be followed to establish a strong foundation for every Scrum project. Keep in mind that the processes don’t have to be carried out separately or sequentially. They can be modified to fit each project’s unique specifications. However, it is crucial to develop a strong project vision and establish the various Scrum roles before moving past the Initiative phase.
Chapter 5: Planning & Estimates Phase
In Scrum, the planning and estimates phase is a crucial part of the project’s initiation. It involves a collaborative effort between the Scrum Team, which includes the Product Owner, Scrum Master, and Development Team, to define the work that needs to be done and estimate the effort required to complete it. This phase typically occurs at the beginning of each sprint.
Here’s an overview of the planning and estimates phase in Scrum:
1. Product Backlog Refinement: The Product Owner prioritizes and updates the Product Backlog, which is a list of all desired features, enhancements, and bug fixes for the product. The Scrum Team collaborates to refine the backlog items, ensuring they are well-understood, appropriately sized, and ready for implementation.
2. Sprint Planning Meeting: The Scrum Team holds a Sprint Planning meeting, which is time-boxed to a specific duration (usually a few hours for a one-month sprint). During this meeting, the team selects the backlog items they will work on during the upcoming sprint. The Product Owner explains the high-priority items, and the Development Team asks questions to gain clarity.
3. Definition of Done: The Development Team and Product Owner define the “Definition of Done” (DoD). The DoD sets the quality criteria that must be met for a product increment to be considered complete. It typically includes factors such as functionality, performance, testing, documentation, and user acceptance.
4. Estimation Techniques: The Development Team estimates the effort required for each selected backlog item. Common estimation techniques in Scrum include:
a. Story Points: The team assigns relative values to backlog items using story points. Story points measure the complexity and effort required for implementation, considering factors such as size, risk, and uncertainty.
b. Planning Poker: This is a collaborative estimation technique where team members use playing cards with numbers (e.g., Fibonacci sequence) to indicate their estimate for a backlog item. The team discusses and reaches a consensus on the estimation.
5. Sprint Backlog: The selected backlog items, along with their estimates, are added to the Sprint Backlog, which is a subset of the Product Backlog. The team collectively commits to completing the selected work within the sprint.
6. Sprint Goal: The Scrum Team establishes a Sprint Goal, which provides a clear objective for the sprint and guides the team’s focus and decision-making throughout the iteration.
The planning and estimates phase sets the foundation for the upcoming sprint, enabling the team to prioritize work, estimate effort, and establish a shared understanding of the goals and expectations. It helps in creating a realistic plan and promotes transparency and collaboration within the Scrum Team.
Product Epics
In Scrum, product epics are large bodies of work that capture high-level initiatives or features. They represent significant deliverables that provide value to the end-users or customers. Product epics are typically too large and complex to be completed within a single sprint and require further breakdown into smaller, more manageable user stories.
Source: Delibr Blog
Here are some key points about product epics in Scrum:
1. Definition: Product epics are often described as large user stories or collections of related user stories. They represent a substantial piece of functionality or a feature set that contributes to the overall product vision and goals.
2. Size and Complexity: Epics are bigger in scope and complexity compared to regular user stories. They cover a broader range of requirements, involve multiple user personas or user flows, and may span across several sprints or even multiple releases.
3. Strategic Initiatives: Product epics typically align with strategic initiatives or long-term goals of the product. They address major functionalities, major improvements, or significant changes to the product that require substantial effort and resources.
4. Breaking Down Epics: Since epics are too large to be implemented directly, they need to be broken down into smaller, more manageable user stories. This breakdown happens during backlog refinement or sprint planning sessions. User stories derived from epics are often more detailed and have clearer acceptance criteria.
5. Epics and the Product Backlog: Product epics reside in the Product Backlog alongside other user stories and backlog items. They are usually prioritized and ranked by the Product Owner based on factors such as business value, customer needs, and market demands.
6. Evolving Nature: Epics can evolve and change over time as the product and its requirements become better understood. As the team gains more insights, they may refine and re-prioritize epics, breaking them down further into smaller user stories.
7. Agile Roadmap and Release Planning: Product epics play a crucial role in creating an Agile roadmap and release planning. They provide a high-level view of the major deliverables and milestones, helping the team and stakeholders understand the product’s evolution and progress.
By using product epics, the Scrum Team can organize and prioritize work effectively, communicate the product vision, and ensure that the most valuable and strategic initiatives are addressed.
Chapter 6: Sprint Planning Meeting
The sprint planning meeting is a collaborative session in Scrum where the Scrum Team plans the work to be accomplished during an upcoming sprint. This meeting is time-boxed and occurs at the beginning of each sprint, typically after the previous sprint review and retrospective. The sprint planning meeting involves the Product Owner, Scrum Master, and the Development Team.
The sprint planning meeting holds significant importance in Scrum for multiple reasons. Firstly, it establishes goal clarity by defining the objective of the sprint. This shared understanding aligns the efforts of the Scrum Team and promotes collaboration towards a common purpose.
Secondly, the meeting facilitates work selection and prioritization. Through collaboration between the Product Owner and Development Team, the most valuable and feasible Product Backlog items are chosen for the sprint. This ensures that the team focuses on work that aligns with the product vision, customer needs, and business priorities.
Source: www.hygger.io/blog
Another crucial aspect is capacity and commitment. By estimating tasks and assessing capacity, the Development Team determines a realistic amount of work they can complete during the sprint. This enables them to set a sustainable pace and make a commitment to delivering a specific set of items by the end of the sprint.
The sprint planning meeting also promotes collaboration within the Scrum Team. It provides a platform for discussion, clarification, and shared decision-making among team members. This fosters transparency, allowing everyone to have a clear understanding of the work to be accomplished and how it aligns with the overall product vision.
Additionally, the meeting serves as a forum for adaptability and iterative planning. If new information or insights arise, the team can adjust their plans, refine backlog items, or reprioritize work based on the current understanding. This flexibility enables the team to respond to changes effectively.
Overall, the sprint planning meeting lays the foundation for the upcoming sprint. By creating the Sprint Backlog, the team has a detailed plan of what needs to be done and can start executing the work immediately after the meeting. This minimizes confusion, fosters transparency, and ensures a clear direction for the team’s productivity and success throughout the sprint.
Here’s an overview of the sprint planning meeting in Scrum:
Attendees
The sprint planning meeting involves the entire Scrum Team, which includes the Product Owner, Scrum Master, and Development Team members. Stakeholders and other interested parties may also attend as observers, but they don’t actively participate in the decision-making process.
Meeting Duration
The sprint planning meeting has a predefined time-box, which is determined based on the length of the sprint. For example, for a two-week sprint, the meeting is typically limited to four hours. The Scrum Master ensures that the meeting stays within the time-box.
Meeting Purpose
The sprint planning meeting serves two primary purposes:
a. Establishing the Sprint Goal: The Scrum Team collaboratively defines the sprint goal, which is a concise statement that encapsulates the overall objective for the sprint. The sprint goal provides focus and direction to the team during the sprint.
b. Selecting and Planning Sprint Backlog Items: The Scrum Team selects the top-priority items from the Product Backlog and plans the work required to complete them in the upcoming sprint. These selected items are moved to the Sprint Backlog, which becomes the primary focus for the Development Team during the sprint.
Product Backlog Review
The Product Owner reviews the Product Backlog, ensuring that it is up to date and properly prioritized. The team discusses the items at the top of the backlog, seeking clarification and additional information as needed.
Sprint Goal Discussion
The Product Owner describes the objective of the sprint and the desired outcomes. This helps the Development Team understand the purpose of the sprint and align their efforts accordingly.
Task Estimation and Commitment
The Development Team breaks down the selected Product Backlog items into smaller tasks and estimates the effort required to complete each task. They consider factors such as complexity, dependencies, and available capacity. Based on these estimations, the Development Team determines how many items they can commit to completing during the sprint.
Sprint Backlog
The selected Product Backlog items, along with their estimated tasks, are added to the Sprint Backlog. This backlog becomes the Development Team’s plan for the sprint and provides transparency regarding the work that needs to be accomplished.
Meeting Conclusion
The sprint planning meeting concludes when the Scrum Team has a clear understanding of the sprint goal, the selected Product Backlog items, and the corresponding tasks. Any additional questions or concerns are addressed, and the team is ready to start the sprint.
The sprint planning meeting facilitates collaboration, alignment, and commitment within the Scrum Team. It enables the team to establish a shared understanding of the sprint goal, select work items, and plan their efforts effectively for the upcoming sprint.
Curriculum
Leading IT Transformation – Workshop 22 – Implementing Scrum
- Define your Scrum Team
- Scrum Master
- Product Owner
- Initiation Phase
- Planning & Estimates Phase
- Sprint Planning Meeting
Distance Learning
Introduction
Welcome to Appleton Greene and thank you for enrolling on the Leading IT Transformation corporate training program. You will be learning through our unique facilitation via distance-learning method, which will enable you to practically implement everything that you learn academically. The methods and materials used in your program have been designed and developed to ensure that you derive the maximum benefits and enjoyment possible. We hope that you find the program challenging and fun to do. However, if you have never been a distance-learner before, you may be experiencing some trepidation at the task before you. So we will get you started by giving you some basic information and guidance on how you can make the best use of the modules, how you should manage the materials and what you should be doing as you work through them. This guide is designed to point you in the right direction and help you to become an effective distance-learner. Take a few hours or so to study this guide and your guide to tutorial support for students, while making notes, before you start to study in earnest.
Study environment
You will need to locate a quiet and private place to study, preferably a room where you can easily be isolated from external disturbances or distractions. Make sure the room is well-lit and incorporates a relaxed, pleasant feel. If you can spoil yourself within your study environment, you will have much more of a chance to ensure that you are always in the right frame of mind when you do devote time to study. For example, a nice fire, the ability to play soft soothing background music, soft but effective lighting, perhaps a nice view if possible and a good size desk with a comfortable chair. Make sure that your family know when you are studying and understand your study rules. Your study environment is very important. The ideal situation, if at all possible, is to have a separate study, which can be devoted to you. If this is not possible then you will need to pay a lot more attention to developing and managing your study schedule, because it will affect other people as well as yourself. The better your study environment, the more productive you will be.
Study tools & rules
Try and make sure that your study tools are sufficient and in good working order. You will need to have access to a computer, scanner and printer, with access to the internet. You will need a very comfortable chair, which supports your lower back, and you will need a good filing system. It can be very frustrating if you are spending valuable study time trying to fix study tools that are unreliable, or unsuitable for the task. Make sure that your study tools are up to date. You will also need to consider some study rules. Some of these rules will apply to you and will be intended to help you to be more disciplined about when and how you study. This distance-learning guide will help you and after you have read it you can put some thought into what your study rules should be. You will also need to negotiate some study rules for your family, friends or anyone who lives with you. They too will need to be disciplined in order to ensure that they can support you while you study. It is important to ensure that your family and friends are an integral part of your study team. Having their support and encouragement can prove to be a crucial contribution to your successful completion of the program. Involve them in as much as you can.
Successful distance-learning
Distance-learners are freed from the necessity of attending regular classes or workshops, since they can study in their own way, at their own pace and for their own purposes. But unlike traditional internal training courses, it is the student’s responsibility, with a distance-learning program, to ensure that they manage their own study contribution. This requires strong self-discipline and self-motivation skills and there must be a clear will to succeed. Those students who are used to managing themselves, are good at managing others and who enjoy working in isolation, are more likely to be good distance-learners. It is also important to be aware of the main reasons why you are studying and of the main objectives that you are hoping to achieve as a result. You will need to remind yourself of these objectives at times when you need to motivate yourself. Never lose sight of your long-term goals and your short-term objectives. There is nobody available here to pamper you, or to look after you, or to spoon-feed you with information, so you will need to find ways to encourage and appreciate yourself while you are studying. Make sure that you chart your study progress, so that you can be sure of your achievements and re-evaluate your goals and objectives regularly.
Self-assessment
Appleton Greene training programs are in all cases post-graduate programs. Consequently, you should already have obtained a business-related degree and be an experienced learner. You should therefore already be aware of your study strengths and weaknesses. For example, which time of the day are you at your most productive? Are you a lark or an owl? What study methods do you respond to the most? Are you a consistent learner? How do you discipline yourself? How do you ensure that you enjoy yourself while studying? It is important to understand yourself as a learner and so some self-assessment early on will be necessary if you are to apply yourself correctly. Perform a SWOT analysis on yourself as a student. List your internal strengths and weaknesses as a student and your external opportunities and threats. This will help you later on when you are creating a study plan. You can then incorporate features within your study plan that can ensure that you are playing to your strengths, while compensating for your weaknesses. You can also ensure that you make the most of your opportunities, while avoiding the potential threats to your success.
Accepting responsibility as a student
Training programs invariably require a significant investment, both in terms of what they cost and in the time that you need to contribute to study and the responsibility for successful completion of training programs rests entirely with the student. This is never more apparent than when a student is learning via distance-learning. Accepting responsibility as a student is an important step towards ensuring that you can successfully complete your training program. It is easy to instantly blame other people or factors when things go wrong. But the fact of the matter is that if a failure is your failure, then you have the power to do something about it, it is entirely in your own hands. If it is always someone else’s failure, then you are powerless to do anything about it. All students study in entirely different ways, this is because we are all individuals and what is right for one student, is not necessarily right for another. In order to succeed, you will have to accept personal responsibility for finding a way to plan, implement and manage a personal study plan that works for you. If you do not succeed, you only have yourself to blame.
Planning
By far the most critical contribution to stress, is the feeling of not being in control. In the absence of planning we tend to be reactive and can stumble from pillar to post in the hope that things will turn out fine in the end. Invariably they don’t! In order to be in control, we need to have firm ideas about how and when we want to do things. We also need to consider as many possible eventualities as we can, so that we are prepared for them when they happen. Prescriptive Change, is far easier to manage and control, than Emergent Change. The same is true with distance-learning. It is much easier and much more enjoyable, if you feel that you are in control and that things are going to plan. Even when things do go wrong, you are prepared for them and can act accordingly without any unnecessary stress. It is important therefore that you do take time to plan your studies properly.
Management
Once you have developed a clear study plan, it is of equal importance to ensure that you manage the implementation of it. Most of us usually enjoy planning, but it is usually during implementation when things go wrong. Targets are not met and we do not understand why. Sometimes we do not even know if targets are being met. It is not enough for us to conclude that the study plan just failed. If it is failing, you will need to understand what you can do about it. Similarly if your study plan is succeeding, it is still important to understand why, so that you can improve upon your success. You therefore need to have guidelines for self-assessment so that you can be consistent with performance improvement throughout the program. If you manage things correctly, then your performance should constantly improve throughout the program.
Study objectives & tasks
The first place to start is developing your program objectives. These should feature your reasons for undertaking the training program in order of priority. Keep them succinct and to the point in order to avoid confusion. Do not just write the first things that come into your head because they are likely to be too similar to each other. Make a list of possible departmental headings, such as: Customer Service; E-business; Finance; Globalization; Human Resources; Technology; Legal; Management; Marketing and Production. Then brainstorm for ideas by listing as many things that you want to achieve under each heading and later re-arrange these things in order of priority. Finally, select the top item from each department heading and choose these as your program objectives. Try and restrict yourself to five because it will enable you to focus clearly. It is likely that the other things that you listed will be achieved if each of the top objectives are achieved. If this does not prove to be the case, then simply work through the process again.
Study forecast
As a guide, the Appleton Greene Leading IT Transformation corporate training program should take 12-18 months to complete, depending upon your availability and current commitments. The reason why there is such a variance in time estimates is because every student is an individual, with differing productivity levels and different commitments. These differentiations are then exaggerated by the fact that this is a distance-learning program, which incorporates the practical integration of academic theory as an as a part of the training program. Consequently all of the project studies are real, which means that important decisions and compromises need to be made. You will want to get things right and will need to be patient with your expectations in order to ensure that they are. We would always recommend that you are prudent with your own task and time forecasts, but you still need to develop them and have a clear indication of what are realistic expectations in your case. With reference to your time planning: consider the time that you can realistically dedicate towards study with the program every week; calculate how long it should take you to complete the program, using the guidelines featured here; then break the program down into logical modules and allocate a suitable proportion of time to each of them, these will be your milestones; you can create a time plan by using a spreadsheet on your computer, or a personal organizer such as MS Outlook, you could also use a financial forecasting software; break your time forecasts down into manageable chunks of time, the more specific you can be, the more productive and accurate your time management will be; finally, use formulas where possible to do your time calculations for you, because this will help later on when your forecasts need to change in line with actual performance. With reference to your task planning: refer to your list of tasks that need to be undertaken in order to achieve your program objectives; with reference to your time plan, calculate when each task should be implemented; remember that you are not estimating when your objectives will be achieved, but when you will need to focus upon implementing the corresponding tasks; you also need to ensure that each task is implemented in conjunction with the associated training modules which are relevant; then break each single task down into a list of specific to do’s, say approximately ten to do’s for each task and enter these into your study plan; once again you could use MS Outlook to incorporate both your time and task planning and this could constitute your study plan; you could also use a project management software like MS Project. You should now have a clear and realistic forecast detailing when you can expect to be able to do something about undertaking the tasks to achieve your program objectives.
Performance management
It is one thing to develop your study forecast, it is quite another to monitor your progress. Ultimately it is less important whether you achieve your original study forecast and more important that you update it so that it constantly remains realistic in line with your performance. As you begin to work through the program, you will begin to have more of an idea about your own personal performance and productivity levels as a distance-learner. Once you have completed your first study module, you should re-evaluate your study forecast for both time and tasks, so that they reflect your actual performance level achieved. In order to achieve this you must first time yourself while training by using an alarm clock. Set the alarm for hourly intervals and make a note of how far you have come within that time. You can then make a note of your actual performance on your study plan and then compare your performance against your forecast. Then consider the reasons that have contributed towards your performance level, whether they are positive or negative and make a considered adjustment to your future forecasts as a result. Given time, you should start achieving your forecasts regularly.
With reference to time management: time yourself while you are studying and make a note of the actual time taken in your study plan; consider your successes with time-efficiency and the reasons for the success in each case and take this into consideration when reviewing future time planning; consider your failures with time-efficiency and the reasons for the failures in each case and take this into consideration when reviewing future time planning; re-evaluate your study forecast in relation to time planning for the remainder of your training program to ensure that you continue to be realistic about your time expectations. You need to be consistent with your time management, otherwise you will never complete your studies. This will either be because you are not contributing enough time to your studies, or you will become less efficient with the time that you do allocate to your studies. Remember, if you are not in control of your studies, they can just become yet another cause of stress for you.
With reference to your task management: time yourself while you are studying and make a note of the actual tasks that you have undertaken in your study plan; consider your successes with task-efficiency and the reasons for the success in each case; take this into consideration when reviewing future task planning; consider your failures with task-efficiency and the reasons for the failures in each case and take this into consideration when reviewing future task planning; re-evaluate your study forecast in relation to task planning for the remainder of your training program to ensure that you continue to be realistic about your task expectations. You need to be consistent with your task management, otherwise you will never know whether you are achieving your program objectives or not.
Keeping in touch
You will have access to qualified and experienced professors and tutors who are responsible for providing tutorial support for your particular training program. So don’t be shy about letting them know how you are getting on. We keep electronic records of all tutorial support emails so that professors and tutors can review previous correspondence before considering an individual response. It also means that there is a record of all communications between you and your professors and tutors and this helps to avoid any unnecessary duplication, misunderstanding, or misinterpretation. If you have a problem relating to the program, share it with them via email. It is likely that they have come across the same problem before and are usually able to make helpful suggestions and steer you in the right direction. To learn more about when and how to use tutorial support, please refer to the Tutorial Support section of this student information guide. This will help you to ensure that you are making the most of tutorial support that is available to you and will ultimately contribute towards your success and enjoyment with your training program.
Work colleagues and family
You should certainly discuss your program study progress with your colleagues, friends and your family. Appleton Greene training programs are very practical. They require you to seek information from other people, to plan, develop and implement processes with other people and to achieve feedback from other people in relation to viability and productivity. You will therefore have plenty of opportunities to test your ideas and enlist the views of others. People tend to be sympathetic towards distance-learners, so don’t bottle it all up in yourself. Get out there and share it! It is also likely that your family and colleagues are going to benefit from your labors with the program, so they are likely to be much more interested in being involved than you might think. Be bold about delegating work to those who might benefit themselves. This is a great way to achieve understanding and commitment from people who you may later rely upon for process implementation. Share your experiences with your friends and family.
Making it relevant
The key to successful learning is to make it relevant to your own individual circumstances. At all times you should be trying to make bridges between the content of the program and your own situation. Whether you achieve this through quiet reflection or through interactive discussion with your colleagues, client partners or your family, remember that it is the most important and rewarding aspect of translating your studies into real self-improvement. You should be clear about how you want the program to benefit you. This involves setting clear study objectives in relation to the content of the course in terms of understanding, concepts, completing research or reviewing activities and relating the content of the modules to your own situation. Your objectives may understandably change as you work through the program, in which case you should enter the revised objectives on your study plan so that you have a permanent reminder of what you are trying to achieve, when and why.
Distance-learning check-list
Prepare your study environment, your study tools and rules.
Undertake detailed self-assessment in terms of your ability as a learner.
Create a format for your study plan.
Consider your study objectives and tasks.
Create a study forecast.
Assess your study performance.
Re-evaluate your study forecast.
Be consistent when managing your study plan.
Use your Appleton Greene Certified Learning Provider (CLP) for tutorial support.
Make sure you keep in touch with those around you.
Tutorial Support
Programs
Appleton Greene uses standard and bespoke corporate training programs as vessels to transfer business process improvement knowledge into the heart of our clients’ organizations. Each individual program focuses upon the implementation of a specific business process, which enables clients to easily quantify their return on investment. There are hundreds of established Appleton Greene corporate training products now available to clients within customer services, e-business, finance, globalization, human resources, information technology, legal, management, marketing and production. It does not matter whether a client’s employees are located within one office, or an unlimited number of international offices, we can still bring them together to learn and implement specific business processes collectively. Our approach to global localization enables us to provide clients with a truly international service with that all important personal touch. Appleton Greene corporate training programs can be provided virtually or locally and they are all unique in that they individually focus upon a specific business function. They are implemented over a sustainable period of time and professional support is consistently provided by qualified learning providers and specialist consultants.
Support available
You will have a designated Certified Learning Provider (CLP) and an Accredited Consultant and we encourage you to communicate with them as much as possible. In all cases tutorial support is provided online because we can then keep a record of all communications to ensure that tutorial support remains consistent. You would also be forwarding your work to the tutorial support unit for evaluation and assessment. You will receive individual feedback on all of the work that you undertake on a one-to-one basis, together with specific recommendations for anything that may need to be changed in order to achieve a pass with merit or a pass with distinction and you then have as many opportunities as you may need to re-submit project studies until they meet with the required standard. Consequently the only reason that you should really fail (CLP) is if you do not do the work. It makes no difference to us whether a student takes 12 months or 18 months to complete the program, what matters is that in all cases the same quality standard will have been achieved.
Support Process
Please forward all of your future emails to the designated (CLP) Tutorial Support Unit email address that has been provided and please do not duplicate or copy your emails to other AGC email accounts as this will just cause unnecessary administration. Please note that emails are always answered as quickly as possible but you will need to allow a period of up to 20 business days for responses to general tutorial support emails during busy periods, because emails are answered strictly within the order in which they are received. You will also need to allow a period of up to 30 business days for the evaluation and assessment of project studies. This does not include weekends or public holidays. Please therefore kindly allow for this within your time planning. All communications are managed online via email because it enables tutorial service support managers to review other communications which have been received before responding and it ensures that there is a copy of all communications retained on file for future reference. All communications will be stored within your personal (CLP) study file here at Appleton Greene throughout your designated study period. If you need any assistance or clarification at any time, please do not hesitate to contact us by forwarding an email and remember that we are here to help. If you have any questions, please list and number your questions succinctly and you can then be sure of receiving specific answers to each and every query.
Time Management
It takes approximately 1 Year to complete the Leading IT Transformation corporate training program, incorporating 12 x 6-hour monthly workshops. Each student will also need to contribute approximately 4 hours per week over 1 Year of their personal time. Students can study from home or work at their own pace and are responsible for managing their own study plan. There are no formal examinations and students are evaluated and assessed based upon their project study submissions, together with the quality of their internal analysis and supporting documents. They can contribute more time towards study when they have the time to do so and can contribute less time when they are busy. All students tend to be in full time employment while studying and the Leading IT Transformation program is purposely designed to accommodate this, so there is plenty of flexibility in terms of time management. It makes no difference to us at Appleton Greene, whether individuals take 12-18 months to complete this program. What matters is that in all cases the same standard of quality will have been achieved with the standard and bespoke programs that have been developed.
Distance Learning Guide
The distance learning guide should be your first port of call when starting your training program. It will help you when you are planning how and when to study, how to create the right environment and how to establish the right frame of mind. If you can lay the foundations properly during the planning stage, then it will contribute to your enjoyment and productivity while training later. The guide helps to change your lifestyle in order to accommodate time for study and to cultivate good study habits. It helps you to chart your progress so that you can measure your performance and achieve your goals. It explains the tools that you will need for study and how to make them work. It also explains how to translate academic theory into practical reality. Spend some time now working through your distance learning guide and make sure that you have firm foundations in place so that you can make the most of your distance learning program. There is no requirement for you to attend training workshops or classes at Appleton Greene offices. The entire program is undertaken online, program course manuals and project studies are administered via the Appleton Greene web site and via email, so you are able to study at your own pace and in the comfort of your own home or office as long as you have a computer and access to the internet.
How To Study
The how to study guide provides students with a clear understanding of the Appleton Greene facilitation via distance learning training methods and enables students to obtain a clear overview of the training program content. It enables students to understand the step-by-step training methods used by Appleton Greene and how course manuals are integrated with project studies. It explains the research and development that is required and the need to provide evidence and references to support your statements. It also enables students to understand precisely what will be required of them in order to achieve a pass with merit and a pass with distinction for individual project studies and provides useful guidance on how to be innovative and creative when developing your Unique Program Proposition (UPP).
Tutorial Support
Tutorial support for the Appleton Greene Leading IT Transformation corporate training program is provided online either through the Appleton Greene Client Support Portal (CSP), or via email. All tutorial support requests are facilitated by a designated Program Administration Manager (PAM). They are responsible for deciding which professor or tutor is the most appropriate option relating to the support required and then the tutorial support request is forwarded onto them. Once the professor or tutor has completed the tutorial support request and answered any questions that have been asked, this communication is then returned to the student via email by the designated Program Administration Manager (PAM). This enables all tutorial support, between students, professors and tutors, to be facilitated by the designated Program Administration Manager (PAM) efficiently and securely through the email account. You will therefore need to allow a period of up to 20 business days for responses to general support queries and up to 30 business days for the evaluation and assessment of project studies, because all tutorial support requests are answered strictly within the order in which they are received. This does not include weekends or public holidays. Consequently you need to put some thought into the management of your tutorial support procedure in order to ensure that your study plan is feasible and to obtain the maximum possible benefit from tutorial support during your period of study. Please retain copies of your tutorial support emails for future reference. Please ensure that ALL of your tutorial support emails are set out using the format as suggested within your guide to tutorial support. Your tutorial support emails need to be referenced clearly to the specific part of the course manual or project study which you are working on at any given time. You also need to list and number any questions that you would like to ask, up to a maximum of five questions within each tutorial support email. Remember the more specific you can be with your questions the more specific your answers will be too and this will help you to avoid any unnecessary misunderstanding, misinterpretation, or duplication. The guide to tutorial support is intended to help you to understand how and when to use support in order to ensure that you get the most out of your training program. Appleton Greene training programs are designed to enable you to do things for yourself. They provide you with a structure or a framework and we use tutorial support to facilitate students while they practically implement what they learn. In other words, we are enabling students to do things for themselves. The benefits of distance learning via facilitation are considerable and are much more sustainable in the long-term than traditional short-term knowledge sharing programs. Consequently you should learn how and when to use tutorial support so that you can maximize the benefits from your learning experience with Appleton Greene. This guide describes the purpose of each training function and how to use them and how to use tutorial support in relation to each aspect of the training program. It also provides useful tips and guidance with regard to best practice.
Tutorial Support Tips
Students are often unsure about how and when to use tutorial support with Appleton Greene. This Tip List will help you to understand more about how to achieve the most from using tutorial support. Refer to it regularly to ensure that you are continuing to use the service properly. Tutorial support is critical to the success of your training experience, but it is important to understand when and how to use it in order to maximize the benefit that you receive. It is no coincidence that those students who succeed are those that learn how to be positive, proactive and productive when using tutorial support.
Be positive and friendly with your tutorial support emails
Remember that if you forward an email to the tutorial support unit, you are dealing with real people. “Do unto others as you would expect others to do unto you”. If you are positive, complimentary and generally friendly in your emails, you will generate a similar response in return. This will be more enjoyable, productive and rewarding for you in the long-term.
Think about the impression that you want to create
Every time that you communicate, you create an impression, which can be either positive or negative, so put some thought into the impression that you want to create. Remember that copies of all tutorial support emails are stored electronically and tutors will always refer to prior correspondence before responding to any current emails. Over a period of time, a general opinion will be arrived at in relation to your character, attitude and ability. Try to manage your own frustrations, mood swings and temperament professionally, without involving the tutorial support team. Demonstrating frustration or a lack of patience is a weakness and will be interpreted as such. The good thing about communicating in writing, is that you will have the time to consider your content carefully, you can review it and proof-read it before sending your email to Appleton Greene and this should help you to communicate more professionally, consistently and to avoid any unnecessary knee-jerk reactions to individual situations as and when they may arise. Please also remember that the CLP Tutorial Support Unit will not just be responsible for evaluating and assessing the quality of your work, they will also be responsible for providing recommendations to other learning providers and to client contacts within the Appleton Greene global client network, so do be in control of your own emotions and try to create a good impression.
Remember that quality is preferred to quantity
Please remember that when you send an email to the tutorial support team, you are not using Twitter or Text Messaging. Try not to forward an email every time that you have a thought. This will not prove to be productive either for you or for the tutorial support team. Take time to prepare your communications properly, as if you were writing a professional letter to a business colleague and make a list of queries that you are likely to have and then incorporate them within one email, say once every month, so that the tutorial support team can understand more about context, application and your methodology for study. Get yourself into a consistent routine with your tutorial support requests and use the tutorial support template provided with ALL of your emails. The (CLP) Tutorial Support Unit will not spoon-feed you with information. They need to be able to evaluate and assess your tutorial support requests carefully and professionally.
Be specific about your questions in order to receive specific answers
Try not to write essays by thinking as you are writing tutorial support emails. The tutorial support unit can be unclear about what in fact you are asking, or what you are looking to achieve. Be specific about asking questions that you want answers to. Number your questions. You will then receive specific answers to each and every question. This is the main purpose of tutorial support via email.
Keep a record of your tutorial support emails
It is important that you keep a record of all tutorial support emails that are forwarded to you. You can then refer to them when necessary and it avoids any unnecessary duplication, misunderstanding, or misinterpretation.
Individual training workshops or telephone support
Please be advised that Appleton Greene does not provide separate or individual tutorial support meetings, workshops, or provide telephone support for individual students. Appleton Greene is an equal opportunities learning and service provider and we are therefore understandably bound to treat all students equally. We cannot therefore broker special financial or study arrangements with individual students regardless of the circumstances. All tutorial support is provided online and this enables Appleton Greene to keep a record of all communications between students, professors and tutors on file for future reference, in accordance with our quality management procedure and your terms and conditions of enrolment. All tutorial support is provided online via email because it enables us to have time to consider support content carefully, it ensures that you receive a considered and detailed response to your queries. You can number questions that you would like to ask, which relate to things that you do not understand or where clarification may be required. You can then be sure of receiving specific answers to each individual query. You will also then have a record of these communications and of all tutorial support, which has been provided to you. This makes tutorial support administration more productive by avoiding any unnecessary duplication, misunderstanding, or misinterpretation.
Tutorial Support Email Format
You should use this tutorial support format if you need to request clarification or assistance while studying with your training program. Please note that ALL of your tutorial support request emails should use the same format. You should therefore set up a standard email template, which you can then use as and when you need to. Emails that are forwarded to Appleton Greene, which do not use the following format, may be rejected and returned to you by the (CLP) Program Administration Manager. A detailed response will then be forwarded to you via email usually within 20 business days of receipt for general support queries and 30 business days for the evaluation and assessment of project studies. This does not include weekends or public holidays. Your tutorial support request, together with the corresponding TSU reply, will then be saved and stored within your electronic TSU file at Appleton Greene for future reference.
Subject line of your email
Please insert: Appleton Greene (CLP) Tutorial Support Request: (Your Full Name) (Date), within the subject line of your email.
Main body of your email
Please insert:
1. Appleton Greene Certified Learning Provider (CLP) Tutorial Support Request
2. Your Full Name
3. Date of TS request
4. Preferred email address
5. Backup email address
6. Course manual page name or number (reference)
7. Project study page name or number (reference)
Subject of enquiry
Please insert a maximum of 50 words (please be succinct)
Briefly outline the subject matter of your inquiry, or what your questions relate to.
Question 1
Maximum of 50 words (please be succinct)
Maximum of 50 words (please be succinct)
Question 3
Maximum of 50 words (please be succinct)
Question 4
Maximum of 50 words (please be succinct)
Question 5
Maximum of 50 words (please be succinct)
Please note that a maximum of 5 questions is permitted with each individual tutorial support request email.
Procedure
* List the questions that you want to ask first, then re-arrange them in order of priority. Make sure that you reference them, where necessary, to the course manuals or project studies.
* Make sure that you are specific about your questions and number them. Try to plan the content within your emails to make sure that it is relevant.
* Make sure that your tutorial support emails are set out correctly, using the Tutorial Support Email Format provided here.
* Save a copy of your email and incorporate the date sent after the subject title. Keep your tutorial support emails within the same file and in date order for easy reference.
* Allow up to 20 business days for a response to general tutorial support emails and up to 30 business days for the evaluation and assessment of project studies, because detailed individual responses will be made in all cases and tutorial support emails are answered strictly within the order in which they are received.
* Emails can and do get lost. So if you have not received a reply within the appropriate time, forward another copy or a reminder to the tutorial support unit to be sure that it has been received but do not forward reminders unless the appropriate time has elapsed.
* When you receive a reply, save it immediately featuring the date of receipt after the subject heading for easy reference. In most cases the tutorial support unit replies to your questions individually, so you will have a record of the questions that you asked as well as the answers offered. With project studies however, separate emails are usually forwarded by the tutorial support unit, so do keep a record of your own original emails as well.
* Remember to be positive and friendly in your emails. You are dealing with real people who will respond to the same things that you respond to.
* Try not to repeat questions that have already been asked in previous emails. If this happens the tutorial support unit will probably just refer you to the appropriate answers that have already been provided within previous emails.
* If you lose your tutorial support email records you can write to Appleton Greene to receive a copy of your tutorial support file, but a separate administration charge may be levied for this service.
How To Study
Your Certified Learning Provider (CLP) and Accredited Consultant can help you to plan a task list for getting started so that you can be clear about your direction and your priorities in relation to your training program. It is also a good way to introduce yourself to the tutorial support team.
Planning your study environment
Your study conditions are of great importance and will have a direct effect on how much you enjoy your training program. Consider how much space you will have, whether it is comfortable and private and whether you are likely to be disturbed. The study tools and facilities at your disposal are also important to the success of your distance-learning experience. Your tutorial support unit can help with useful tips and guidance, regardless of your starting position. It is important to get this right before you start working on your training program.
Planning your program objectives
It is important that you have a clear list of study objectives, in order of priority, before you start working on your training program. Your tutorial support unit can offer assistance here to ensure that your study objectives have been afforded due consideration and priority.
Planning how and when to study
Distance-learners are freed from the necessity of attending regular classes, since they can study in their own way, at their own pace and for their own purposes. This approach is designed to let you study efficiently away from the traditional classroom environment. It is important however, that you plan how and when to study, so that you are making the most of your natural attributes, strengths and opportunities. Your tutorial support unit can offer assistance and useful tips to ensure that you are playing to your strengths.
Planning your study tasks
You should have a clear understanding of the study tasks that you should be undertaking and the priority associated with each task. These tasks should also be integrated with your program objectives. The distance learning guide and the guide to tutorial support for students should help you here, but if you need any clarification or assistance, please contact your tutorial support unit.
Planning your time
You will need to allocate specific times during your calendar when you intend to study if you are to have a realistic chance of completing your program on time. You are responsible for planning and managing your own study time, so it is important that you are successful with this. Your tutorial support unit can help you with this if your time plan is not working.
Keeping in touch
Consistency is the key here. If you communicate too frequently in short bursts, or too infrequently with no pattern, then your management ability with your studies will be questioned, both by you and by your tutorial support unit. It is obvious when a student is in control and when one is not and this will depend how able you are at sticking with your study plan. Inconsistency invariably leads to in-completion.
Charting your progress
Your tutorial support team can help you to chart your own study progress. Refer to your distance learning guide for further details.
Making it work
To succeed, all that you will need to do is apply yourself to undertaking your training program and interpreting it correctly. Success or failure lies in your hands and your hands alone, so be sure that you have a strategy for making it work. Your Certified Learning Provider (CLP) and Accredited Consultant can guide you through the process of program planning, development and implementation.
Reading methods
Interpretation is often unique to the individual but it can be improved and even quantified by implementing consistent interpretation methods. Interpretation can be affected by outside interference such as family members, TV, or the Internet, or simply by other thoughts which are demanding priority in our minds. One thing that can improve our productivity is using recognized reading methods. This helps us to focus and to be more structured when reading information for reasons of importance, rather than relaxation.
Speed reading
When reading through course manuals for the first time, subconsciously set your reading speed to be just fast enough that you cannot dwell on individual words or tables. With practice, you should be able to read an A4 sheet of paper in one minute. You will not achieve much in the way of a detailed understanding, but your brain will retain a useful overview. This overview will be important later on and will enable you to keep individual issues in perspective with a more generic picture because speed reading appeals to the memory part of the brain. Do not worry about what you do or do not remember at this stage.
Content reading
Once you have speed read everything, you can then start work in earnest. You now need to read a particular section of your course manual thoroughly, by making detailed notes while you read. This process is called Content Reading and it will help to consolidate your understanding and interpretation of the information that has been provided.
Making structured notes on the course manuals
When you are content reading, you should be making detailed notes, which are both structured and informative. Make these notes in a MS Word document on your computer, because you can then amend and update these as and when you deem it to be necessary. List your notes under three headings: 1. Interpretation – 2. Questions – 3. Tasks. The purpose of the 1st section is to clarify your interpretation by writing it down. The purpose of the 2nd section is to list any questions that the issue raises for you. The purpose of the 3rd section is to list any tasks that you should undertake as a result. Anyone who has graduated with a business-related degree should already be familiar with this process.
Organizing structured notes separately
You should then transfer your notes to a separate study notebook, preferably one that enables easy referencing, such as a MS Word Document, a MS Excel Spreadsheet, a MS Access Database, or a personal organizer on your cell phone. Transferring your notes allows you to have the opportunity of cross-checking and verifying them, which assists considerably with understanding and interpretation. You will also find that the better you are at doing this, the more chance you will have of ensuring that you achieve your study objectives.
Question your understanding
Do challenge your understanding. Explain things to yourself in your own words by writing things down.
Clarifying your understanding
If you are at all unsure, forward an email to your tutorial support unit and they will help to clarify your understanding.
Question your interpretation
Do challenge your interpretation. Qualify your interpretation by writing it down.
Clarifying your interpretation
If you are at all unsure, forward an email to your tutorial support unit and they will help to clarify your interpretation.
Qualification Requirements
The student will need to successfully complete the project study and all of the exercises relating to the Leading IT Transformation corporate training program, achieving a pass with merit or distinction in each case, in order to qualify as an Accredited Leading IT Transformation Specialist (ALITTS). All monthly workshops need to be tried and tested within your company. These project studies can be completed in your own time and at your own pace and in the comfort of your own home or office. There are no formal examinations, assessment is based upon the successful completion of the project studies. They are called project studies because, unlike case studies, these projects are not theoretical, they incorporate real program processes that need to be properly researched and developed. The project studies assist us in measuring your understanding and interpretation of the training program and enable us to assess qualification merits. All of the project studies are based entirely upon the content within the training program and they enable you to integrate what you have learnt into your corporate training practice.
Leading IT Transformation – Grading Contribution
Project Study – Grading Contribution
Customer Service – 10%
E-business – 05%
Finance – 10%
Globalization – 10%
Human Resources – 10%
Information Technology – 10%
Legal – 05%
Management – 10%
Marketing – 10%
Production – 10%
Education – 05%
Logistics – 05%
TOTAL GRADING – 100%
Qualification grades
A mark of 90% = Pass with Distinction.
A mark of 75% = Pass with Merit.
A mark of less than 75% = Fail.
If you fail to achieve a mark of 75% with a project study, you will receive detailed feedback from the Certified Learning Provider (CLP) and/or Accredited Consultant, together with a list of tasks which you will need to complete, in order to ensure that your project study meets with the minimum quality standard that is required by Appleton Greene. You can then re-submit your project study for further evaluation and assessment. Indeed you can re-submit as many drafts of your project studies as you need to, until such a time as they eventually meet with the required standard by Appleton Greene, so you need not worry about this, it is all part of the learning process.
When marking project studies, Appleton Greene is looking for sufficient evidence of the following:
Pass with merit
A satisfactory level of program understanding
A satisfactory level of program interpretation
A satisfactory level of project study content presentation
A satisfactory level of Unique Program Proposition (UPP) quality
A satisfactory level of the practical integration of academic theory
Pass with distinction
An exceptional level of program understanding
An exceptional level of program interpretation
An exceptional level of project study content presentation
An exceptional level of Unique Program Proposition (UPP) quality
An exceptional level of the practical integration of academic theory
Preliminary Analysis
Online Article
“The Agile X-Files: The Scrum Mastery Truth is Out There
By Geoff Watts,
Agile Mastery Institute
If you’re anything like me (and a large proportion of the population) you’ll love a good conspiracy theory?
Conspiracy theories are like magnets that attract curious minds, pulling them into an alternate reality full of intrigue and suspense. Some popular examples include the moon landing hoax (a “giant leap” for conspiracies), the flat Earth theory (a round of applause for defying gravity), the belief that Elvis is still alive (we CAN go on together with suspicious minds) and the many explanations for the assassination of JFK (I’ve seen where Oswald supposedly took his shot).
Now, the orthodoxy will tell you there is no connection to the world of Scrum Mastery. But let me tell you a secret…it’s a conspiracy!
While it may seem like a far-fetched idea, there’s a treasure trove of hidden wisdom we can unearth from this enigmatic world to supercharge our Scrum Mastery. In this blog post, we’ll dive into these parallels and see how great Scrum Masters can leverage some of the tactics used by conspiracy theorists to foster culture change in organisations.
When you look past the mainstream media (or surface-level Scrum training courses) and look at what makes these theories so enticing, I’m sure you’ll agree that actually it’s more than just a coincidence.
The Scrum Mastery Connection
In both our Scrum Mastery Pathway and Product Mastery Pathway we cover the topics of cultural change and bringing people along with us on our journey of challenging the status quo. Because, let’s be honest, when it comes to establishing culture change in an organisation, Scrum Masters, agile coaches, Product Owners and Product Managers face several challenges reminiscent of conspiracy theory dilemmas:
• Resistance to Change: Much like the nonbelievers who dismiss the idea of a lizard elite, employees may be hesitant to adopt new ways of working, especially if they’re comfortable with the status quo. Great Scrum Masters are the persuasive force that encourages teams to step out of their comfort zones and embrace the truth of agile methodologies.
• Skepticism and Doubt: Just as some people are skeptical of conspiracy theories like the existence of secret societies, team members may question the efficacy of agile practices. Great Scrum Masters demonstrate the value of agile approaches by providing evidence of successful case studies and highlighting the benefits of agility.
• Misalignment of Goals: Different departments or teams may have conflicting goals, making it difficult to establish a unified vision for change – similar to the disagreements among UFO enthusiasts about the true nature of extraterrestrial visitors. Great Scrum Masters act as peacekeepers, guiding teams towards a shared objective while respecting their diverse perspectives.
• Organisational Structure: Rigid hierarchical structures can hinder collaboration and the flow of information, not unlike the shadowy organisations that allegedly suppress information about the existence of aliens. Great Scrum Masters strive to break down these barriers, fostering a culture of open communication and collaboration to help teams uncover hidden insights and reach their full potential.
Are you ready to navigate the murky waters of cultural change and guide your teams and organisation towards a brighter, more agile future? Well, grab your tinfoil hat, roll up your sleeves, and let’s get to work!
Basic Human Desires
It turns out there are a number of basic human desires that drive the popularity of conspiracy theories and by understanding these innate desires. In our Scrum Mastery Pathways, we teach how Great Scrum Masters use those insights to nudge organisations towards change. Here are a few examples:
• The Secret Society of Agile: Everyone wants to be part of a group, a secret society where they belong. Great Scrum Masters harness this desire, creating an environment where team members feel like they’re part of an exclusive club on a mission to change the world.
• The Allure of the Underdog: Who doesn’t love a good David and Goliath story? Great Scrum Masters capitalise on this fascination by positioning change initiatives as thrilling quests for teams to defy the odds and snatch victory from the jaws of defeat.
• Connecting the Cosmic Dots: People love to see the big picture, even if it’s just a bunch of random stars in the sky. While this can lead to some far-out ideas, great Scrum Masters use this tendency to help teams spot genuine patterns and trends, guiding them towards interstellar problem-solving and decision-making.
Leveraging Conspiracy Theory Tactics for Scrum Mastery
By understanding the tactics used by conspiracy theorists, great Scrum Masters can tackle these challenges and accelerate culture change:
Embrace Skepticism and Critical Thinking
A healthy dose of skepticism is an essential trait for both conspiracy theorists and Scrum Mastery. While conspiracy theorists question established narratives, great Scrum Masters question existing processes and practices to identify opportunities for improvement. By encouraging teams to question the status quo, Scrum Masters can drive innovation and help organisations evolve.
Encourage teams to question existing processes and practices, and be open to new ideas and solutions.
Encourage Collaboration and Communication
Conspiracy theories often revolve around the notion of change—whether it’s a hidden agenda, a global shift, or a transformative event. Similarly, Scrum Mastery is about embracing change and helping teams adapt to new environments and ways of working. By studying the strategies employed by conspiracy theorists to cope with uncertainty, great Scrum Masters develop techniques to help teams navigate change and uncertainty more effectively.
Conspiracy theorists rely on the power of collaboration and communication to gather and share information. They form communities, discuss ideas, and collectively analyse data. Great Scrum Masters also promote collaboration and communication within teams, ensuring that members work together effectively and exchange ideas freely. The open exchange of information is key to developing a shared understanding of team goals and ensuring that everyone is on the same page.
Use Storytelling to Engage and Persuade
Conspiracy theories often rely on storytelling to captivate and persuade their audience. Great Scrum Masters are also skilled at storytelling, as they need to communicate complex ideas and concepts to teams and stakeholders. By understanding the techniques used by conspiracy theorists to craft compelling narratives, Scrum Masters can improve their storytelling skills and better influence the teams they work with.
Craft compelling narratives to illustrate the benefits of change and the potential consequences of maintaining the status quo.
Address Cognitive Biases
Conspiracy theories often tap into cognitive biases that make them attractive and viral. It turns out there’s a whole rogues’ gallery of cognitive biases that can pull the wool over our eyes in the context of Scrum Mastery. Here’s a small selection:
• Confirmation bias: People tend to search for, interpret, and remember information that confirms their pre-existing beliefs. Conspiracy theories often provide explanations that align with an individual’s worldview, making them more appealing and likely to be shared.
• Proportionality bias: This bias leads people to assume that significant events must have equally significant causes. Conspiracy theories often propose elaborate explanations for major events, playing into this cognitive bias.
• Availability heuristic: People are more likely to believe information that is readily available or easily recalled. Conspiracy theories often capitalise on this bias by using memorable and emotionally charged stories.
• Illusory Pattern Perception: Ever connected the dots on your bedroom ceiling? That’s our tendency to see patterns where none exist. Instead of falling for nonexistent patterns, great Scrum Masters leverage this tendency by helping teams recognise and create real patterns in their work processes. By reinforcing positive habits and routines, great Scrum Masters can effectively guide teams towards improved performance and collaboration.
• Groupthink: Great Scrum Masters use the power of groupthink to their advantage by carefully curating a team culture that values open communication, continuous improvement, and adaptability. By fostering an environment where these values become the norm, great Scrum Masters ensure that groupthink works in favor of agile principles.
• Sunk Cost Fallacy: This is the tendency to continue investing in a project or decision based on the amount already invested, rather than evaluating its current worth. Great Scrum Masters use the sunk cost fallacy as a teaching moment to encourage teams to reevaluate their commitments and priorities regularly. By focusing on the value of present and future work rather than past investments, great Scrum Masters can help teams become more adaptive and responsive to change.
Understanding these cognitive biases and their role in the appeal of conspiracy theories can help Scrum Masters promote Scrum Mastery and recognise potential pitfalls in their own thinking and communication. By being aware of these biases, great Scrum Masters can work to mitigate their impact on team dynamics and decision-making.
Conclusion
Although conspiracy theories and Scrum Mastery may seem worlds apart, they share intriguing parallels that can help great Scrum Masters foster culture change within organisations. By leveraging the tactics used by conspiracy theorists and addressing the specific challenges of implementing change, great Scrum Masters can help organisations embrace new ways of working, drive innovation, and achieve success.
Serious disclaimer: This blog post is not intended to promote misinformation or propaganda. The goal is to explore the parallels between conspiracy theories and Scrum Mastery to help accelerate culture change within organisations.
So, let’s take inspiration from the world of conspiracy theories (without promoting misinformation) and harness these tactics to accelerate culture change and uncover the truth about how to liberate our organisations!
Keep an open mind, question the status quo, and never stop spreading your message. Who knows what other unexpected connections we may find along the way? Happy hunting!”
If you would like to view the original article, please visit: www.agilemasteryinstitute.com
Online Article
“What is Success for a Scrum Master?
By Vasco Duarte,
Infoq.com
Today is your first day. This probably not the first time you take up the role of Scrum Master, but today is different. You are facing a new team, a new organization. A totally different set of challenges.
You have done this before, but not in this context, not with this team, not with this organization. How do you adapt? How do you take on the challenge of this new team? What tools can you use from your past experience to help you succeed in this context? You did take note of the tools you used in the past, didn’t you?
We have all been in a similar situation, or we will be in the future. If we want to succeed as Scrum Masters we have to create our own approach to the different teams and organizations that we will work with. Fortunately we don’t need to create that approach and design our Scrum Master tools alone. We have many useful resources out there that help us create our own Scrum Master toolbox. From excellent hands-on books such as #Workout by Jurgen Appelo, to the classics like Peopleware by DeMarco and Lister, to the more coaching focused Coaching Agile Teams by Lyssa Adkins. But the best way to learn is to talk to many Scrum Masters, with diverse experiences. From this diversity of experiences we can build our own approaches and get inspiration to try different approaches until we find the one that works in our particular context.
The most important lesson learned by experienced Scrum Masters
How do you measure success in the first place? The most common lesson learned shared by experienced Scrum Masters is: to achieve success you must first define success and measure your way there. Each Scrum Master has a slightly different way of doing it, but they all do it. Below are some concrete examples and questions you can use to measure your own success as a Scrum Master.
1. Define your way to measure success, and follow your own development just as you would follow the development of the team. Jeff Kosciejew listed three questions that he follows to assess his own success:
1. Did the team deliver production ready software this Sprint?
2. Was everyone happy with, and proud of what they achieved?
3. Did we improve our way of working (e.g. did we deliver more value than in the previous Sprint?)
This approach of having your own questions as a Scrum Master seems to be popular among other Scrum Masters as well. Dominic Krimmer created his own checklist to assess his performance as a Scrum Master:
1. Do we have a Team Vision?
2. Do we have a clearly defined Sprint goal or focus?
3. Do we keep our Scrum board up to date to make our work visible and transparent?
4. Do we have a dashboard to communicate to others the status of our product?
5. Do we have good quality stories?
Finally Stefano Porro suggests another list of questions:
1. Does the team, and the team members feel that their contribution is valued and seen as important?
2. Does the team feel happy to work in this project?
3. Does the team, given a choice, want to work with you as their Scrum Master again in the future?
4. Is the “index of participation” in the daily standup at the right level? (The index of participation = number of non-solicited interventions that affect how the team works.)
Which questions you use to measure your success is not as important as the fact that you have your own list of questions, or your own checklist that you regularly follow to help you focus your attention on the right topics, the topics that require your attention to develop your skills as a Scrum Master. As Andy Deighton put it: at first you may ignore your definition of success, but sooner or later you need a compass, a way to measure your own development as a professional Scrum Master. Ask yourself: am I ignoring my success as a professional Scrum Master?
The most common of definition of success for Scrum Masters and how to achieve it
What was the most common symptom of a successful outcome for your work as a Scrum Master? I’m glad you asked: by far the most common definition of success listed by the 30+ interviewees in the podcast was: the team “owns” the process. This lesson has come in many different forms, from having teams own the meetings or ceremonies in the Scrum process, to having the team actively interact with other teams and stakeholders in the organization. The tough question for Scrum Masters is: how do we help teams “own” the process? Here are some of the tools listed by experienced Scrum Masters:
2. Be away for a few days and assess how the team took ownership of the process and meetings. Matt Dominici, who suggested this idea, tells us that the level of ownership can only be seen when you are away. If you return from a few days hiatus and find the team lost, and the process abandoned, that’s a clear sign that the team is not yet ready to “own” the process. But don’t despair, this tool is also useful because when you come back you can assess what is missing, or not taken care of by the team and focus your coaching attention on those topics. For example, if you come back to find that the team has abandoned the testing of their changes, then you know that the team still needs help understanding that part of the work, or is missing tools that help them integrate testing into their daily work.
3. Focus on defining and providing a platform for your team. Jeff Kosciejew builds on his experience as a music player to explain how some instruments (or roles) are there to provide the right conditions and the environment that enables others to succeed. He calls that a “platform” on which the team builds. Scrum Masters must do the same; so one important characteristic for Scrum Masters is to be comfortable with being in the background, in a supporting and enabling role. Each different ceremony requires a different approach to creating that platform. In the daily standup meeting, for example, you can simply remove yourself from the circle. Step back while the team is discussing topics related to their work, and step in when they need your support, or you must intervene to facilitate the meeting. This physical withdrawal will help the team realize that you are there to support them, and will encourage them to take ownership of the meeting.”
If you would like to continue reading this article, please visit: www.infoq.com
Online Article
“5 Dos And Don’ts During Sprint Planning
By Naveen Kumar Singh,
Scrum.org
I got the idea of writing this blog while hosting a webinar on the same topics when multiple people told us to document our discussion.
These dos and don’ts are my experiences, so I would like to hear yours too. Feel free to connect to me on LinkedIn for further discussion.
Top 5 Things You Should Do During Sprint Planning
1st – Craft Sprint Goal
As per Scrum Guide – The Sprint Goal is an objective that will be met within the sprint by implementing the Product Backlog, and it guides the Development Team on why it is building the Increment.
During the Sprint Planning, the Product Owner presents business objectives for the Sprint and an ordered Product Backlog. The Scrum Team discusses what can be done based on the Definition of Done and crafts the Sprint Goal and forecasts their work. Scrum Teams ensure they have a meaningful Sprint goal, not a Generic goal. For example, “policy renewal for individual policyholders” for an insurance product rather than saying, the goal is “complete all Product Backlog Items selected during the Sprint.”
Challenges in crafting the Sprint Goal:-
• The team has random Product Backlog Items, so struggle to craft a sprint goal. It can be avoided by having ordered product backlog, but if it is still needed, the team can ask the product owner about the most crucial Product Backlog Item and set a goal around that.
• The team picks up work for more than one product as they are supporting multiple products. The team can avoid by widening the definition of a product or shortening Sprint duration.
• Team working on multiple components and Items are for components, not for a feature. Avoid such issues through having user-centric features as a Backlog item.
• Team working on support items like defects, incidents, and service requests. A meaningful Sprint Goal optimizes and improves product quality to reduce such defects and incidents.
2nd – Pick at least one retrospective commitment for the sprint
The whole purpose of the Retrospective is to improve the way of working either by adopting new processes, practices, and tools besides improving team collaboration and relationships among team members. Since the team has come up with a few Retrospective commitments so the team must plan 1-2 items for the Sprint or else, it will never get adopted, and teams may struggle to understand the retrospective’s usefulness. For example, the team has agreed to develop mock-ups for Backlog items to gain more clarity upfront to reduce ambiguity, so they must consider and plan the same in the Sprint.
3rd – Refer Definition of Done
The Definition of Done is a common understanding within the Scrum Team on what DONE means, and it evolves as the team learns more about the product and technical skills. It reflects the maturity of the team and improving the quality of a product. Referring to the Definition of Done helps the team to understand how much work they can plan for the Sprint. An exhaustive list of items in the Definition of Done means fewer product backlog items as teams have to do a lot more to complete each Backlog item. For example, if the team has added automated regression testing to improve quality, it may need little more time to write an automated test script for Backlog items.
4th – Review Team capacity
The velocity is good to forecast, but only when the team remains the same working in the consistent sprint cycle. If any of these changes or a few holidays are coming up, it is better to check available team capacity during planning besides team velocity.
5th – Come up with a plan for the initial few days
Since sprint planning is a timebox and the team must respect the timebox, sometimes teams struggle to formulate the Sprint Plan. For example, there is ambiguity in requirements or teams, not sure how to do it better instead of planning more. It may turn out to be counterproductive. It doesn’t mean teams should not prepare a plan but having a lightweight plan for the initial few days is good enough to start. Teams can meet again to plan during the development as they learn more about requirements and ways to accomplish work.
Top 5 Things You Should Avoid Doing During Sprint Planning
1st – Don’t assign stories to developers
The Development Team pulls work from the Product Backlog to the Sprint Backlog, and I think everyone understands that. The Product Owner or the Scrum Master should not assign work to the Development Team. The Development Team Members should also not just divide like your story vs. my story. The Development Team should look for the possibility to see how they can complete stories incrementally within the Sprint by working together. It is more like 2-3 team members pull one story to complete within 2-4 days collectively. It helps in minimizing spillover as they can get feedback early to adjust changes if needed. It also helps the team care about each other and learn each different skills to support when needed.
2nd – Don’t create skills-based tasks
Having sub-tasks like design, coding, writing test cases, functional testing and code reviews, etc., promote a mini-waterfall kind of process during development. Not having sub-tasks may sound good, but it has to be done carefully to avoid transparency issues. Having component-based tasks like mobile interface, web interface, backend service, integration, etc. is better as it promotes collective ownership. Skill-based tasks may impact the transparency and generate more technical debts too. You can read more about it here.
3rd – Don’t force the development team to match the velocity
Velocity is not a way to measure productivity. See how to maximize work value by enabling teams to work on high valued Product Backlog Items. Velocity is good for forecasting when there is no change in the Sprint cycle and team composition. It is like based on speed on the highway cannot help measuring how much one can travel within an hour in city traffic. Similarly, changing drivers will impact speed, so not possible to forecast based on previous driver velocity if there is a new driver.
4th – Don’t plan only defects for the sprint
Focus on how to reduce defects by influencing factors that cause so many defects. Having a few stories helps in learning the expectations of the stakeholders. See how the team plans to reduce the technical debt because more technical debts mean higher total cost of ownership. Look for possibilities to adopt excellent technical practices such as Behavior-Driven Development, Agile Analysis, and other Extreme Programming practices.
5th – Don’t have a generic sprint goal
A generic goal doesn’t define a clear purpose of the Sprint. Have a specific sprint goal and ordered Product Backlog Items around that helps the team to stay focus throughout development. Goals like high-quality work, meet all acceptance criteria or deliver all the backlog items are not a good goal and these are part of the Definition of Done. Think about users and see how users can benefit from the outcome of the Sprint.”
If you would like to continue reading this article, please visit: www.scrum.org
Course Manuals 1-6
Course Manual 1: Define your Scrum Team
What is a scrum team?
A scrum team is a team of collaborators, usually composed of five to nine people, who work together to develop products and complete projects. One product owner, a few developers, and a scrum master make up the basic scrum team. There is no hierarchy or rank in a scrum team. Instead, it is a group of obedient, cohesive people.
Scrum teams base their project management methodology on the Scrum framework. Continuous improvement, adaptability, and respectful teamwork are at the core of the Scrum framework. The 2001 Agile Manifesto and its 12 Principles, which are texts designed to help teams of software developers work effectively, are aligned with Scrum as an approach. The Agile Manifesto bases its methods on the following principles:
• Individuals and interactions come before processes and tools.
• Working products come before comprehensive documentation.
• Customer collaboration comes before contract negotiations.
• Reflecting on processes and implementing changes comes before following a plan.
Scrum and Agile methodologies have dominated offices for the past 20 years and have shown to be quite successful at streamlining collaborative projects. Overall, the Scrum framework supports teams as they strive for highly structured, reflective, and process-centered workflows.
Scrum Team Structure
Successful team structures are designed specifically for high-performing agile teams. One of the most important aspects of any agile project’s success is the composition of the Scrum team. Ineffective collaboration, severe integration hurdles, multitasking, low morale, and other issues will result from poorly formed teams.
When evaluating how teams are structured, take into account these nine characteristics of agile teams and make the appropriate modifications.
1. Despite the size of the project itself, Scrum teams are small. In a good design, teams typically consist of five to nine people. Two pizzas can serve as a meal for each team.
Instead of making each team larger, it is preferable to have numerous small teams working on the same feature (see Scaling the Scrum team below). Sub-teams and hierarchies are not present in agile teams.
2. Teams using Scrum are established to provide functional features from beginning to end. Only specific and clearly justifiable situations, such as creating reusable user interface elements, granting access to a database, or performing a similar service, call for the employment of component teams. However, these must be the exceptions.
3. Cross-functional teams are essential to Scrum because they play up the team members’ strengths, mitigate their limitations, and encourage their incentives.
Cross-functional does not imply that everyone can perform all tasks. Every team will contain specialists. Agile team members are generally encouraged to grow their skill sets so they may periodically step in to help the team deliver on their commitment.
But keep in mind that when people are forced to constantly do activities they are lousy at or dislike, they are more likely to lose interest.
4. Teams self-organize and, as a result, are as empowered and independent as they can be. Teams that self-organize are not assembled at random. They are intentionally nourished and structured such that they are liberated to handle their own work.
People always question whether or not everyone should be treated equally under self-organization, including the junior intern who just joined. In reality, as the CDE model reveals, self-organization necessitates the exact opposite: there must be distinctions among the self-organizing individuals.
5. In an ideal scenario, each sprint results in the delivery of a new product increment thanks to effective teamwork. Multitasking will be reduced to a manageable level in a well-designed Scrum team environment for a business that is not aiming to undertake too many concurrent projects. Consider using a different team structure or postponing some tasks if more than 20% of the team’s members are on several teams.
6. The most successful agile teams are enduring. Teams should be organized to maximize their time spent together.
It takes time for people to learn how to get along with one other. By keeping teams together as long as feasible, you can spread the cost of that learning across a longer time frame.
7. Reduce the number of channels of communication between teams. There will be what seems like a limitless number of communication channels between teams if the Scrum team structure is poorly designed. Teams will discover that they cannot finish any work without first coordinating with an excessive number of other teams.
Coordination between teams will always be necessary. However, the communication overhead is too great if a team that wishes to add a new field to a form is forced to coordinate that effort with three other teams.
8. Effective team designs do, however, promote internal and external communication amongst teams that may not otherwise do so. This is particularly true for remote teams or individuals.
The fact that doing so will improve communication between those teams is one good reason to have someone on two teams. Splitting a person’s time between two teams is easy justifiable if there is a problem with poor communication between them.
9. Team members should have a say in how the group is structured. This could not be achievable when switching to Scrum in its early phases. By the end of each sprint, people might not yet have enough experience providing tested, usable solutions that work.
Similar to this, some people may first be too hostile to Scrum to contribute positively to conversations about the scrum team structure. It is permissible in these circumstances for managers not on the team to create the first structure of the scrum team.
How Agile Teams Work Together
The members of a scrum team collaborate to select a set of tasks to do within a given time frame (an iteration or sprint), and then they self-organize to decide how to complete those tasks.
In order to create a plan (sprint backlog) for delivering the work during sprint planning, developers break down items from the product backlog (typically user stories) into tasks. They do this by adhering to an established definition of done when completing tasks.
The team then gets together for a daily scrum to review and adjust in order to achieve the sprint target. Teams receive feedback on what they produced at the conclusion of each sprint (sprint review), and they examine and adjust their teamwork (sprint retrospective).
Cross-functional, at its core, refers to a team-first method of collaboration that emphasizes teamwork and rewards.
Team members work together to execute tasks throughout each sprint, frequently beginning independently but coming together to finish. They will have to do work that is already done.
Teams using Scrum aim for a steady pace. One of the more challenging Scrum phrases is “sprint,” which while describing a short distance still suggests an aggressive pace.
Product development is more like running a marathon; teams must pace themselves at each stage to avoid exhaustion before completing the project. A development team shouldn’t start the following sprint while still recovering from the previous one. Instead, they ought to secure just enough work to keep their cadence consistent.
Scaling the Scrum Team
Scrum initiatives scale through the use of teams of teams rather than a huge team. Over a thousand people have worked on projects using Scrum. Naturally, figuring out if you can get by with fewer workers should be a priority.
Although it is not the only item required to scale Scrum, using a “Scrum of Scrums” meeting is a well-known method. The Scrum of Scrums meeting is attended by one representative from each Scrum team, who serves as the point person for coordinating the work of several Scrum teams.
While not always occurring, these meetings are comparable to the daily Scrum meeting. A Scrum of Scrums meeting twice a week is sufficient in many workplaces.
The example below demonstrates how a Scrum of Scrums promotes cross-team communication.
Source: Mountain Goats Software
A Scrum team’s members are each represented by a circle. Eight or nine people are on each squad in the bottom row of this picture. To coordinate work above each team, one member from each team (the shaded circle) also takes part in a Scrum of Scrum. A Scrum of Scrum of Scrums is used by those teams to further coordinate their activities.
Benefits of a scrum team
Even outside of the software development business, many organizations have found success with the scrum team methodology, mostly because it makes project management and product release simpler. Utilizing the Scrum framework frequently leads to an end product with increased value since it encourages quick and effective work toward project completion goals. The following are some of the most striking advantages of utilizing a scrum team to advance project management within your company:
Work happens simultaneously
Instead than working on separate project components in order, Scrum teams work on them simultaneously. This helps the team members involved save time by enabling them to make ongoing, crucial changes during the project’s development rather than at the very end. Additionally, multitasking fosters team collaboration and enables teams to incorporate other perspectives into their work. The quality of the finished items can only gain from this. As a result, scrum teams not only generate work of a higher standard, but frequently in less time than is typically required.
Workflow processes are made clear
The scrum framework has certain workflow standards that assist teams in staying on track and concentrating on their final objectives. Project planning, release planning, sprint planning, sprints, daily scrum, sprint review, and retrospective are all steps that Scrum teams go through. These phases all call for various forms of cooperation. For instance, sprints are brief development cycles that usually span between one day and four weeks, during which the team concentrates on building shippable products. The workflow is clearer for everyone since these stages are explicit in their expectations and because all team members are expected to participate in these procedures.
Return on investment (ROI) increases and risk decreases
Organizations that use scrum teams typically see an increase in their ROI, or the ratio of profits to costs on their investment. Teams using the Scrum methodology collaborate more rapidly and effectively than teams using other models. As a result, they tend to make less expensive mistakes over time and occasionally even require less effort. A company’s return is frequently higher as a result of investing less money in the conclusion of a high-value project. Additionally, a corporation may enjoy reduced investment risk in project management if it frequently collaborates with a productive scrum team that boosts ROI.
Team morale improves
The Scrum framework and underlying Agile principles are intrinsically human-oriented, focusing on the procedures and success of the workforce. Face-to-face interaction, self-organizing alliances, feedback channels, and sustainability in development are all valued by scrum teams. The Scrum framework also mandates a reflective approach in which teams assess what is and is not working for their project or product in order to modify workflow as necessary.
Roles in a scrum team
Within a scrum team, there are a few basic jobs, and while team members collaborate as a whole, each role has its own unique duties and responsibilities. In actuality, a large number of scrum team members hold specialized qualifications that give them the necessary skill set for their positions. The people in these positions collaborate strategically to increase the value of their project, inspire one another, and remove any barriers to production.
The main individuals that make up a scrum team are as follows:
Scrum master
The scrum master is often a person who is knowledgeable about or certified in the Scrum framework. They guide other team members through various processes using their knowledge. In essence, a scrum master acts as the foreman of a particular project, keeping team members on task and providing them with coaching on Scrum principles as they go. On a scrum team, there is typically just one scrum master. A scrum master’s responsibilities include:
• Fostering an effective, collaborative work environment for team members
• Understanding Scrum framework and Agile principles
• Mentoring team members on following Agile principles
• Strategically motivating team members at key intervals
• Maintaining productive relationships with stakeholders and team members alike
• Shielding the team from any distractions that may interrupt productivity
Product owner
A scrum team’s product owner is in charge of creating high-value products. They are experts in managing development teams, and they carefully examine project choices to make sure they complement the objectives of the team. Product owners have a thorough awareness of corporate procedures and beliefs that prioritize serving customers. Similar to the scrum master, a scrum team typically only has one product owner. A product owner’s responsibilities include:
• Establishing a product vision and developing a marketing strategy
• Monitoring potential customer engagement and requirements
• Analyzing ROI and suggesting project adjustments to increase ROI
• Proactively coming up with solutions for the development team
• Streamlining the workflow of the development team to increase product value
• Ordering and managing project backlogs
The development team
The development team is made up of experts who are in charge of creating a final product that is of a high caliber and might be released at the conclusion of a project’s sprints. The development team is typically made up of highly trained, collaborative people who are adept at time management, organization, and problem-solving. A key component of scrum teams is the development team, and among its responsibilities are:
• Finding practical solutions to project backlog items
• Working collaboratively without individual titles or hierarchy
• Using a cross-functional approach to ensure they have all the expertise necessary to complete projects
• Delivering shippable products within project time increments
• Acting with accountability for project success
Stakeholders
Anyone who is invested in or has an interest in the project is considered a stakeholder. Stakeholders do provide input and can have an impact on a project’s outcome, even though they are typically not regarded as having a core role in scrum teams because they are not involved in the product creation process. They contribute a variety of viewpoints and frequently speak for other departments or outside businesses. The following responsibilities belong to stakeholders:
• Providing practical feedback to scrum team members on products
• Encouraging project processes that focus on established goals and outcomes
• Communicating with the product owner, scrum master and scrum team to facilitate product functionality
Gmail Development by using a Scrum Team
A Google developer started the Gmail project with the intention of creating web-based email. They used vertical slicing to construct this, and numerous scrum teams were formed to meet the main program objective.
The scrum teams work in synchronized sprints on various tasks, and after each sprint, the modules are integrated together by the integration scrum team.
For each assignment, the integration scrum team has its own specialized scrum team, product owner, and scrum master.
The integration scrum team oversees all system-level development work for the integration of functionality created by each team that feeds into it as well as the architectural integration of the separate scrum teams.
Let me explain how this worked:
1. The separate scrum team develops the functionality for compose functionality.
2. Another team worked on spell check functionality.
3. The third team develops the functionality for search.
4. The integration scrum team does the development work to integrate the functionality together into a the package that the Gmail integration team can integrate into the entire Email module.
Course Manual 2: Scrum Master
A Scrum master is in charge of making sure the Scrum team adheres to the established procedures. One of the tasks of the Scrum master is to remove impediments and sources of distraction from the team’s path. The person in this position serves as the link between the Scrum team and other individuals or teams.
The role of a Scrum Master is very limited in scope, but it has a huge impact on every aspect of a business. A Scrum Master does not participate in the conceptualization or planning of products; instead, they work in the background. As a project manager, they serve more as a liaison between development teams and owners of specific products or lines of business. Scrum Masters must also combine soft skills with the newest tools and approaches because agile processes are completely dependent on people and teamwork. After all, software projects involve a lot of moving components, and when buried in code, individual programmers can easily lose sight of the bigger picture. While avoiding chokepoints, a Scrum Master, on the other hand, keeps a high-level perspective, assisting teams in understanding organizational and technical interdependence. This fosters an environment of accountability and makes it possible for teams to achieve pressing deadlines.
So now, as you are well aware of what a scrum master is, it’s time for you to understand the roles and responsibilities of a scrum master.
What Does a Scrum Master Do?
Source: Atlassian
The following are some of the primary duties of a Scrum Master:
• Facilitate the Scrum process: The Scrum Master makes sure that the team adheres strictly to the Scrum procedure. Conducting Scrum rituals like Sprint Planning, Daily Standup, Sprint Review, and Sprint Retrospective is part of this.
• Remove roadblocks: The Scrum Master is in charge of figuring out and getting rid of any roadblocks that might be stopping the team from producing value. This might cover everything from team dynamics to technical problems.
• Coach the team: The Scrum Master is in charge of educating the team on the values and procedures of Scrum. This includes assisting the group in self-organization and ongoing process improvement.
• Protect the team: The Scrum Master is in charge of keeping the team safe from interruptions and outside distractions. This enables the team to concentrate on its work and provide value.
• Facilitate communication: The Scrum Master is in charge of making sure that the team, the Product Owner, and any other stakeholders are all in the loop.
• Ensure transparency: The Scrum Master is in charge of making sure that all stakeholders are aware of the team’s progress. This includes keeping a burn-down chart and visible product backlog.
Responsibilities of a Scrum Master
1. Use project management techniques and best practices
The Scrum Master is in charge of forming and onboarding project teams, integrating them into the company, and articulating a distinct product vision. The Scrum Master also helps the project team and outside entities communicate and share information. Additionally, they keep an eye on how projects are doing, give prompt feedback, and promote a culture of adaptability and learning.
2. Keep everyone informed and on track
Daily team meetings are held by the scrum master to discuss potential obstacles, get updates on the project’s development, and make sure it is moving forward. Additionally, they have frequent meetings to update the project’s stakeholders on its progress (or lack thereof). In the end, a Scrum Master’s responsibility is to make sure that the team is producing the intended results while meeting deadlines.
3. Present agile engineering techniques
Scrum Masters promote the use of automation and continuous integration (CI) to increase productivity. Using CI solutions, developers commonly merge code snippets into a central repository, from which automated builds and tests are executed across a series of iterations. The risk, time, and effort associated with conventional development techniques are decreased by this repeatable methodology. For instance, if a bug shows up in one build, the next build can easily correct it. Pair programming is another agile method that Scrum Masters promote, in which two developers work together in real-time at the same workstation. Together, these techniques shorten the length of the development process and enhance the product’s architecture and quality.
4. Coach Team Members
The product owner and development team are coached by the scrum master. One of their main duties is to make sure the team has received sufficient training in Agile methods, that the team members are committed to the project, and that they are aware of their individual roles. The Scrum Master ensures that the teams are self-managed, just like a real coach would. They are always looking for ways to increase productivity and team performance.
5. Organize regular stand-up meetings.
By leading daily stand-up meetings, sprint planning sessions, sprint reviews, and other events, the Scrum Master keeps the team focused and organized. Teams talk about their accomplishments, what they have planned for the day, and any challenges they are having with the assignments during these quick sessions. The Scrum Master is responsible for making sure that everyone on the team, even those who work remotely, can join in and participate in meetings.
6. Assist the Product Owner With the Product Backlog
The team’s to-do list is referred to as the product backlog. The task of creating and maintaining the product backlog falls on the shoulders of the product owner and is subject to change depending on the state of the work and the requirements for development. Using the data received from standup meetings, the Scrum Master assists the product owner in maintaining and improving the backlog. They arrange review sessions and give user stories first priority.
7. Remove Roadblocks
The Scrum Master aids the team in maintaining focus on the tasks that must be completed throughout each iteration. The Master does this by removing any obstacles or detours that would prevent the squad from moving forward. For instance, if team members are required to attend an excessive number of pointless meetings, it may interfere with work. The Scrum Master can work with the meeting hosts to make sure that only those team members are necessary to attend each meeting. As an alternative, the Scrum Master can engage with product owners and stakeholders to ensure that the workload is allocated if a member of the team is required to work on numerous teams.
8. Teach Scrum Practices and Principles
The Scrum Master is an expert in all of the main Scrum procedures and practices. To ensure a seamless onboarding process for new team members and employees, they act as a mentor. The Scrum Master keeps work moving forward and assists new team members in comprehending the goals and objectives of a product. They are responsible for ensuring that the team adheres to Scrum principles and guidelines while working. They give the group advice on how to maintain their own organization and attention, which boosts output.
Why Is a Scrum Master Necessary for Scrum Teams?
A Scrum Master is required to lead a scrum team. To make sure the scrum team adheres to the genuine Scrum procedure throughout a project, the Scrum Master job is crucial.
Having a Scrum Master with appropriate working experience to coach, mentor, and facilitate the new Scrum team can be incredibly beneficial at the foundational level. As a result, Scrum masters are frequently hired as consultants rather than full-time employees.
In contrast to what businesses frequently claim, the Scrum Master’s job remains even when the Scrum framework evolves over time. To ensure that work proceeds as efficiently as possible inside the Scrum framework, every scrum team benefits from having the aid of a Scrum Master.
Differences Between a Scrum Master and Product Manager
Differences Between a Scrum Master and Project Manager
Top Qualities of a Successful Scrum Master
1. Influential
A Scrum Master guides several teams working on a project to meet predetermined deliverables and milestones. At the organizational level, they must be able to inspire various groups and stakeholders, maximizing the potential of everyone involved. The Scrum Master’s role as team leader involves bridging the conceptual and practical aspects of the project. The Scrum Master needs to be an effective leader and manager.
2. Collaborative
The Scrum Master serves as a crucial conduit between project teams and the product owner. The Scrum Master supports the team while the product owner leads the overall effort. Successful products that satisfy the needs of the organization are ultimately the consequence of effective collaboration between the Scrum Master and product owner. To provide the requested product, a skilled Scrum Master should be able to think of innovative approaches to boost cooperation, organization, and productivity.
3. Observant
The Scrum Master is a team member and facilitator rather than a manager. They should be attentive to the difficulties the project team is having at every stage and good listeners. The Scrum Master should also be perceptive, keeping tabs on the group’s daily activities to get a clear picture of everyone’s responsibilities and contributions during sprints.
4. Knowledgeable
The Scrum Master should not only address current difficulties but also proactively avert future ones. This necessitates comprehensive product and process knowledge. The team can avoid obstacles thanks to the Scrum Master’s experience. The XP, Lean, and Kanban frameworks, as well as other agile approaches, should all be familiar to the Scrum Master.
The Indicators for Scrum Master Success
How can you tell if your scrum master is capable? What are signs of a successful Scrum Master? Is one of the desired signals the frequent use of the Confluence retrospective template? Or, given the variety of success variables, is it pointless to try to grasp the contributing components? The performance of the Scrum team as a whole is rarely directly related to a Scrum Master, who by definition has no power.
Continue reading to discover nine straightforward insights on how Scrum Masters may help a self-managing team succeed.
1. Delivering value: Every Sprint, the Scrum team produces a valuable increment. Scrum as a framework is concentrating on delivery. Undoubtedly, there are several difficulties with this. Everything else, however, is less significant if a Scrum team is not consistently generating value for the stakeholders (internal and external). Building confidence among stakeholders is a secondary benefit of giving important Increments on a regular basis. Building their trust usually leads to less monitoring, such as reporting responsibilities or committees tampering with Scrum—you get the point. All of this promotes self-management, which improves the effectiveness and enjoyment of working as a Scrum team.)
2. People want to join the Scrum team: Since success is the only thing that succeeds, more people want to join the Scrum team. (The ability of participants to vote with their feet is a reliable predictor of a Scrum Master’s success in both directions. My advice is to routinely conduct anonymous polls within the Scrum team to determine whether team members would suggest an open position within the company to a close friend who has an agile mindset. You should also constantly monitor the growth of this “employer NPS®” to identify patterns.)
3. Upholding the Scrum Values: Successful Scrum Masters consistently uphold the Scrum Values, and all other Scrum team members do the same. The morale of our Scrum team is excellent as a result.
4. Promoting psychological safety: Closely related to upholding the Scrum Values, transparency in the Scrum team’s internal and external communications with stakeholders is a telltale indicator of a successful Scrum Master. The Scrum team will be substantially more effective, boosting the return on investment, if everyone feels free to express their ideas.
5. Creating an egalitarian team structure: Self-management is crucial on one hand. On the other hand, there is no hierarchy and no sub-roles in a Scrum team. Any effective Scrum Master promotes such a setting. Gaining the respect and trust of your fellow Scrum teammates is the foundation for leadership and authority (because the Scrum team is collectively accountable for the team’s success).
6. Fostering self-management: The Scrum team is managing itself; the Scrum Master is not required to hold hands or play Bob Marley at 9:58 a.m. every morning. Success as a scrum master depends on being “invisibly present,” as well. By the way, effective Scrum Masters may have a good vacation because they don’t purposely make the Scrum team reliant on them. The Scrum team gradually gains independence as it learns.)
7. The Kaizen mentality: The Scrum team is intrinsically motivated to improve the way it works, comprehend the issues and potential solutions of its clients, and consider how it may contribute to the success of the company and the general welfare of the commonwealth. (This ongoing effort at improvement includes a dedication to product quality and avoiding excessive technological debt.)
8. No enforcement of Scrum: Scrum Masters that are successful do not do this. (Please note: Scrum must be pulled; it cannot be forced onto someone. Additionally, we are compensated to solve our clients’ problems rather than to apply Scrum. Beyond Scrum, there are probably other effective ways to accomplish this. For instance, Kanban is frequently a wise decision.)
9. Seeing the big picture: The key to any Scrum Master’s success is assisting the team members in seeing the big picture of the issue and potential solutions. For instance, by mastering the art of product discovery and developing workable Product Backlogs. (trash in, trash out: A subpar Product Backlog will not get your Scrum team any praise from clients or the organization, regardless of how well they practice Scrum in general.)
Furthermore, I believe that “good knowledge of the Scrum framework” is self-evident. Or would you describe a surgeon who is already adept with a knife as “successful”?
The 8 Stances of a Scrum Master
The Scrum Guide states that the Scrum Master is in charge of ensuring that Scrum is understood and used. This is accomplished by scrum masters by making sure the scrum team follows the scrum philosophy, practices, and rules.
For the Scrum Team, the Scrum Master serves as a servant-leader. The Scrum Master assists people who interact with the Scrum Team outside the Scrum Team in determining which interactions are beneficial and which are not. To optimize the value produced by the Scrum Team, the Scrum Master works with everyone to modify these interactions.
The position of a scrum master can take on many different forms and is very diverse. Depending on the circumstance and context, a competent Scrum Master is aware of them and knows when and how to apply them. All with the intention of assisting individuals in comprehending the Scrum philosophy.
Source: Serious Scrum
The Scrum Master Acts as a:
• A servant leader who prioritizes the needs of their team and the people to whom they deliver value (the customer), with the aim of generating outcomes consistent with the organization’s values, guiding principles, and strategic goals.
• A facilitator who creates the environment and establishes limits so that the team may work together.
• A coach working with the individual, the team, and the company to truly collaborate with the Scrum team while focusing on mindset and behavior.
• A manager who is in charge of removing waste, managing obstacles, the process, the team’s well-being, controlling the scope of self-organization, and managing culture
• A mentor who imparts team members’ knowledge and experience of Agile.
• A teacher to ensure that Scrum and other pertinent techniques are comprehended and used.
• A remover of impediments who addresses obstacles to the team’s progress while taking into account the development team’s capacity for self-organization.
• A change agent to foster an environment where Scrum Teams can thrive.
The 8 Misunderstood Stances of a Scrum Master
Source: Serious Scrum
The desired 8 positions of a Scrum Master may seem like plain sense, but that is not to say that everyone follows them. Too frequently, the position of a scrum master is misinterpreted and seen as someone acting in…
• A Scribe. taking notes throughout Scrum activities. recording the whole Sprint plan, daily plan, refinement meetings, and commitments from the Retrospective. I’ve had customers who wanted the “Scrum Master” to serve as a scribe for 4 hours each week.
• A Secretary. Including the schedule of all the Scrum events. accountable for updating the teams’ holiday and vacation schedule.
• The Scrum Police. Rigidly adhering to the Scrum guidelines without showing any consideration for the context or present circumstances of the team. You’re doing it incorrectly if you’re not acting in accordance with the Scrum Guide.
• The Team Boss. The team’s manager, although being referred to be the “servant-leader”. a boss’s hiring and firing authority. the superior who determines whether a worker qualifies for a pay raise.
• The Admin.T he Scrum Master is your friend if you need a change in JIRA, TFS, or any other application. Every process is rote knowledge to him (or her).
• The Chairman. The group gives the Daily Scrum leader a status report each morning. The Scrum Master might use this to gather the data needed to create the daily status report for his or her superiors.
• A Super Hero. Bird, that is. It’s an aircraft. The Super Scrum Master is here! removing all of your obstacles before they became actual obstacles. The hero is dependent on the adrenaline rush that comes from fixing “problems.” It’s not about the group; it’s about elevating his hero status.
• The Coffee Clerk. Getting coffee for your team members is not a problem. This is really professional. But if your primary duty is to make the team coffee throughout the day, you’re missing the point of being a scrum master.
Scrum Master Success — Conclusion
There isn’t a straightforward checklist that can be used to determine good Scrum Masters. It is exceedingly difficult to link the accomplishments of a Scrum team with the specific acts of a Scrum Master because they are truly servant-leaders without any kind of authority. Most likely, some Scrum teams are productive without their Scrum Masters.
If you take a closer look at the nine Scrum Master success patterns that have been offered, you will see that they are all built on the same fundamental ideas: Adopting self-management, focusing on quality, adopting Scrum for complicated adaptive challenges rather than just any problem, and getting everyone on board with the why, what, and how.
Scrum Masters have a wide range of influence inside any contemporary firm, despite their many areas of specialization. Above all else, they are in charge of embracing and putting agile principles into practice in order to boost team productivity, efficiency, and the caliber of the deliverables they are tasked with producing.
How Dropbox’s Scrum Master drives success
Dropbox’s founder, Drew Houston, first encountered problems when he tried to share his images with his fiancée since her computer was malfunctioning. So he made the decision to develop a free service that makes it simple to store and exchange files. He was unaware that it would increase in value to $10 billion over ten years later. As the vice president of operations, Houston recruited Scott Van Winkle in 2013. Van Winkle introduced Scrum, a software development methodology, to Dropbox.
The entire team first opposed this shift in working method, but with the support of their scrum master, they quickly found that scrum doesn’t take up a lot of time from their days and also assisted them in discovering new prospects to expand their company. Dropbox’s income increased by 20% every month after implementing scrum for just three months, and it doubled in just a year.
The Dropbox crew began working at specific periods throughout the day and concentrating entirely on that one issue. Houston was regularly provided with progress updates, and he could observe the development and change in the product immediately following each week. He was aware of what people required and what they still lacked.
The fact that designers, developers, and salespeople collaborate as a team is key to the software’s success. Scrum enables them to achieve this.
Course Manual 3: Product Owner
Building a new product or feature isn’t simple, and getting it to take off in the market is a much bigger problem. the Scrum product owner is here.
The needs of the consumer are satisfied by good products, right? Having a dedicated employee who speaks for your customers is crucial.
What is a Scrum product owner?
A Scrum product owner serves as a team leader, a spokesperson for their clients, and an authority on the product backlog.
Source: manifesto
Engineers and developers collaborate in scrum teams to establish objectives for a 30-day project, or “sprint.” Then, they collaborate with the product owner and management to create the product by the deadline.
Product Owner Vs Scrum Product Owner
You might be wondering how product owner differs from “Scrum” since I only discussed them briefly.
The way they operate is where the biggest distinction lies. All of the duties that product owners perform are usually geared toward the product launch.
Scrum product owners, on the other hand, employ that Agile strategy that we previously covered. They produce work in shorter, digestible pieces called sprints.
A Scrum product owner and a conventional product owner frequently collaborate to get a project done. One is in charge of the specific product sprints, and the other is in charge of the overall product launch.
Project Manager vs. Product Owner
Some POs and Scrum Masters have experience in project management. A few distinctions need to be considered by project managers who intend to go from project management to product ownership.
• A project manager is seated apart from the group. A member of the Scrum team is the product owner.
• A project manager is in charge of making sure the project is successful. A product’s success is the responsibility of the entire Scrum team.
• Some project managers are directly in charge of managing the team. On a Scrum team, product owners often don’t have any direct reports.
• Project managers choose project schedules and due dates, then divide work accordingly. Based on their present understanding of the product, POs convey the range of functionality that the team will provide by a specific date and rely on their teams to provide realistic estimate ranges.
• By limiting changes, project managers try to complete a project that has been previously outlined. At the conclusion of each sprint, POs evaluate the product and modify its features and plans in light of their findings.
If they are ready to give up some of their conventional duties and give the team more authority than in a traditionally managed project, project managers can make good product owners.
Business analyst vs product owner
Due to the time commitment of the position, product owners are frequently busy. The most typical technique to increase their capability is by expanding the team with another business analyst or system analyst.
Business analysts frequently receive responsibility for the functionality of one or more product areas that POs allocate to them.
For instance, in tax preparation software, the business analyst may be entrusted with comprehending new depreciation legislation. The analyst would conduct the essential product backlog items investigation and writing. The product owner typically retains control over assigning priorities to the work that the analyst has identified.
Some business analysts graduate to product ownership, while others prefer to work as team members, where they can draw on their experience to help break down user stories and unearth buried needs.
Let’s talk more about the role of a Scrum product owner.
Scrum Product Owner Role
Product Visionary
The technical and conceptual architecture of the product is developed by the Scrum product owner. They develop the concept for the product, then present the product development teams with the blueprint.
Then, during the development phase, the product owner is in charge of maximizing the value of the product or feature. Product owners accomplish this through prioritizing user feedback, encouraging team collaboration, and coming up with new features.
Marketplace Expertise
Scrum product owners exhibit a high level of expertise in both the company’s products and their target market.
They prioritize developing customer-centric features and are inspired by the success of their clients. They have a responsibility to comprehend the demands, difficulties, and responses clients have when dealing with their business.
Scrum product owners must also have a thorough understanding of the organization’s product management system.
They must be aware of the skills of their development teams in order to set challenging but achievable objectives.
Product owners who lack this knowledge risk being pushy or pushing their engineering and design teams too far.
Why You Need a Scrum Product Owner
Voice of the Customer
Due to their role as the customer’s voice, Scrum product owners are a crucial position in Scrum teams. They have a responsibility to convey the product management team’s basic principles and take into account the needs of the client.
Product managers continually collect client feedback and incorporate it into the development process. Designers and engineers can produce better products that go above and beyond what customers expect by doing this.
Quality Control
Scrum product owners provide as a degree of quality control when a product is being developed. They ensure that the final product adheres to the original aim of the undertaking.
The product owner can rearrange team efforts to satisfy the project’s original objectives if it appears to be veering off course. The product owner has the ultimate approval to make sure the feature or product satisfies its purpose once development is finished.
Organization
It can be difficult to know how to direct the development process when developing a new product.
Scrum product owners oversee the project by setting up engineering teams and establishing long-term objectives for staff members to work toward.
They help teams to fulfill deadlines by using fast team-building exercises that promote product management.
Additionally, teams may swiftly share information to improve the efficiency of the development process by establishing this open system of communication.
Scrum Product Owner Responsibilities
Source: linkedin
Define Product Roadmap
The creation and improvement of the team’s product roadmap is one of the primary duties of a Scrum product owner.
Remember that the Scrum product owner is responsible for determining the most effective means of achieving the overall product goal.
The product roadmap serves as an action plan that unites the team on the particular goals for the product, how those goals will be met, and how progress will be evaluated along the way.
Team priorities are now clearly defined, and the project’s course is determined.
Anyone on the team ought to be able to consult the product roadmap to respond to inquiries like:
• Who is responsible for which task?
• How far along is the project?
• How much further advancement is needed to accomplish the goal?
Manage Product Backlog
Scrum product owners keep track of consumer obstacles and look for solutions in order to develop products that satisfy customer needs. They achieve this by developing and managing a shared product backlog with product management.
The product owner is in charge of answering any queries from their team members regarding the specifics of the product backlog.
Product Backlog
A comprehensive list of potential products or features that address consumer complaints makes up a product backlog. The Scrum product owner creates it by identifying patterns in customer feedback and adding solutions to these obstacles to the product backlog. The product owner then ranks the ideas on this list in order of priority and distributes them to the engineering and design teams so that development can start.
Research Target Audience and Marketplace
The Scrum product owner researches new trends in the marketplace and with the target audience when revising the product backlog.
They carry out studies like evaluations of customer behavior and look into user preferences in product usage records.
These quantitative statistics support the trends that product owners see while analyzing customer stories. Scrum product owners might have more faith in their suggested ideas if patterns can be empirically supported.
Motivate Product Development
Promoting goal achievement is a key duty of Scrum product owners. Their responsibility is to maintain the team’s commitment to hitting the goals established during the product roadmap phase.
Scrum product owners encourage development teams to succeed by holding daily stand-ups and sprint planning meetings. Teams are able to stay focused on development because to these frequent check-ins.
Let’s now discuss some of the abilities and characteristics that a top-notch Scrum product owner possesses.
Scrum Product Owner Skills and Traits
Team-Oriented
The project may be led by the product owner, but the best owners are driven by the accomplishments of their teams.
Product owners must be flexible when presenting their ideas and encourage team members to look for improvements even though they come up with the overall design.
Ineffective product owners micromanage their teams. Instead, they urge staff members to improve the product. Employees remain actively involved as a result because they have a greater stake in the success of the product.
Effective Communicator
Translating client needs into a product that development teams can create is the responsibility of the Scrum product owner.
Because the vision of their product must be understood by all company stakeholders, product owners must be good team communicators.
They also give harsh criticism to the dedicated engineers they depend on to complete projects on time. Product owners consistently strike a balance between stakeholder interests throughout the development process.
How fragmented communication can lead to Scrum failure: Project X – A scheduling system for a large organization in the energy sector
This case is from 2008 and is a good example of a multi-regional, multi-vendor Agile project that, in the opinion of one of the project’s engineers, failed. Why did the project get a failing grade? According to the engineer, the job ended up costing five times more than originally planned and taking three times as long as expected.
It was initially ambitious to bring together teams for a year-long project with monthly Agile sprints from Canada offered by one vendor, the US and some of Europe given by another. Co-located and remote employees made up the 4 Scrum teams, and the Scrum Master for 2 of the teams worked remotely but visited the team site about once per month.
The issues with Project X:
In 2019, many businesses are still struggling to get the hang of remote employment. We didn’t have the same technologies available to us today more than ten years ago. As ‘individuals and interactions over tools and processes’ is one of the core concepts of the Agile Manifesto, a distant Agile project back then might have succeeded if communication was prioritized above all else. Sadly, no, it wasn’t.
There were sporadic and non-time sensitive communications between the teams, and especially between the vendors. Moreover, the non-co-located Scrum master was ineffective in their position because standups did not follow Agile norms. The client’s expectations of the Agile software development process were different from those of Vendor A’s. They had immature Agile processes, to put it simply.
Lessons learned: To ensure that everyone is on the same page, create a clear Agile development plan in advance and adhere to it. Agile requires clear communication, thus if remote work is required, it must be supported consistently by a certain real-time tech communications infrastructure.
Business Savvy
A product needs to stand out from its rivals in order to succeed on the market.
Scrum product owners need to have a deep awareness of their industry and client base to produce products that stand out from the competition.
Customers’ success is prioritized in the decision-making process of successful product owners who are customer-focused.
Adaptable
Speaking of decision-making, Scrum product owners must be adaptable and quick to act.
If the project isn’t fulfilling the original vision they had in mind, they must not be scared to change direction.
On the basis of fresh consumer trends or the caliber of the product output, this may occasionally need adjusting the product strategy or schedule.
Scrum product owners collaborate cross-functionally with a variety of teams, therefore these abilities are useful. Next, we’ll talk about a handful of those.
Who Scrum Product Owners Work With
Cross-Departments
To get a holistic picture of the customer experience, Scrum product owners collaborate with the marketing, sales, and customer support teams.
The buying habits of consumers are outlined in valuable consumer reports and current market trends that marketing teams have access to.
Sales teams interact directly with consumers and can communicate details about specific obstacles that are upsetting leads.
Additionally, customer service representatives offer first-hand knowledge of how customers interact with the product.
Upper Management
The product owner serves as a point of contact between the product management teams and senior management as the project’s manager.
They inform managers of their advancement and detail any modifications being made to the development process. They also convey expected completion dates for the product as well as predicted deadlines.
External Stakeholders
Scrum product owners must take into account the needs of all their external stakeholders even though the success of the client is the main priority.
This comprises stakeholders who have financial stakes in the firm and care about the product’s commercial viability.
Product owners use first-party data to illustrate the possible advantages of their new feature or product in order to win over these groups.
Leveraging a Scrum Product Owner at Your Company
Scrum product owners are valuable experts that can assist you in creating products that are genuinely oriented around the requirements of your target market.
The Scrum Developer’s Role
The Accountabilities of a Developer
Developers are the members of the Scrum Team who are dedicated to producing any component of a useable increment each Sprint, as stated in the Scrum Guide.
What does a Developer do?
It’s crucial to keep in mind that a developer isn’t always a software development. They can concentrate on any area of the product’s design, development, testing, or shipping, whether it involves software or not. The precise abilities required by developers are frequently diverse and change depending on the kind of job they are undertaking. The Developers, however, are always responsible for
• Planning the Sprint and the Sprint Backlog
• Fostering quality through adherence to a Definition of Done
• Modifying their daily plans in order to progress toward the sprint goal
• Holding one another accountable as colleagues
Beyond these obligations, Developers may also face situations in which they must adopt techniques like facilitating, mentoring, instructing, and coaching. For instance:
• The Daily Scrum is an event for the Developers of the Scrum Team and someone needs to facilitate that event. The team self manages to designate the facilitator.
• A developer may possess abilities that others lack, enabling them to mentor, train, or teach other team members how to perform a task. Pair programming, where developers collaborate to exchange knowledge and learn from one another, is a fantastic opportunity to make use of these abilities.
Remembering to uphold the Scrum Values is crucial for developers and all other Scrum Team Members. There may be times when they need, for instance, the following qualities: Courage to bring up team disagreements so that they can be resolved jointly; Openness to accept each other’s ideas; Focus on the task they are doing and care to avoid becoming sidetracked; Commitment to the development of a Done Increment; Respect for each and every Scrum Team member, as well as for their thoughts.
Course Manual 4: Initiation Phase
The initiate phase consists of six processes:
1. Create a Project Vision
What is project vision?
You should first be aware of what you are trying to write before putting pen to paper and attempting to articulate your vision. Project vision and project vision statement are two terms with various definitions that are relevant here. The project vision is the overarching, big picture goal that the team or project wants to achieve. On the other hand, the statement functions as a kind of tool for succinctly and clearly articulating this vision.
Simply described, a project vision statement is the project’s vision in writing. Its purpose is to direct, encourage, and motivate those involved in the project. With only a few phrases, it conveys the overall sentiment better than anything else. The vision statement communicates the team’s basic beliefs and ultimate objective rather than providing instructions on how to behave in every given situation. The team or individual team members might decide how to proceed with the project based on this information.
“A project vision answers why, the essential starting point for inspiring action.” – Robert B. Sowby PMTimes
The importance of a vision statement in outlining the direction in which the project should proceed cannot be overstated. It aids in the proper decision-making for your team members. It inspires people to finish tasks that are essential for achieving the desired result. Additionally, it motivates fresh initiatives or fixes to get the intended outcome. It is difficult and important to take project vision statements seriously when they incorporate all of these elements. There are several vision statement templates available online, but none are a great fit for everyone. While there are no strict requirements for the format of this statement, several recommendations are made.
Source: Visual Paradigm
How to identify project vision?
Usually, a project vision is established by holding a meeting with the stakeholders, the product owner, and the scrum master. In order to create a project vision statement that is effective, the meeting helps establish the business environment, business requirements, and stakeholder expectations.
Writing it down
Write your project vision statement after you have clarified and comprehended the project vision. Unfortunately, writing what makes sense to you alone is insufficient; you also need to consider how to effectively convey your ideas to the team. What expressions, words, and phrasing will they respond to most favorably? To ensure that you create something that motivates action, take into account the following factors.
1. Keep it brief and simple to grasp. Your project vision statement should be simple to understand and simple to recall at all times. The less ambiguity there is for your team members to interpret in their own way, the shorter and clearer you can make it. Additionally, they are more likely to adhere to it if they can quickly recall it.
2. Be specific but unbiased. Your vision statement should outline the project’s ultimate objective as well as any other requirements. It shouldn’t, however, be concentrated on a single strategy for achieving this final result. Instead, it should allow for multiple routes to the desired outcome and promote teamwork among stakeholders.
3. Consider the horizon. Your project vision statement should concentrate on your goals for a specific period of time. Instead of concentrating on what you want right now, create your objectives based on where you want to be in 5, 10, or 20 years. Consequently, you will be moving your business forward and striving to achieve specific goals in a set amount of time.
4. Make it inspiring and difficult. Your vision statement ought to be about a goal that the entire team is enthusiastic about achieving. At the same time, this objective ought to be a task that can be accomplished over the long term, not only right away. This will motivate your team to put in extra effort in order to obtain anything feasible along the way.
5. Avoid becoming overly specific. Write your vision down with some room for revisions. Since it is hard to predict what will occur over the following five years, keeping your aim ambiguous ensures that it will still be relevant in the future.
6. Express yourself in writing. The most effective vision statements discuss both who you are as a group or organization and who you hope to become.
It is crucial to keep in mind that the project vision statement is not a comprehensive project schedule. The remarks typically include all or at least some of the aforementioned points in just a few short phrases.
Collaborate
Choosing a project vision can be a solitary endeavor, but creating the project vision statement need not be. It’s a good idea to involve the entire team in the process, or just a portion of it. As a result, regardless of distance, you should ensure that everyone participates. It will be easier to utilize language that the team can relate to and that makes them feel like they are a part of the team and the overall objective.
Best examples
Even if all of this sounds excellent, are you still confused of the specifics of your project’s vision statement? Let’s start by looking at some quotes from some of the biggest corporations in the world. Rather than being for a single project, these vision statements serve as examples of how such statements can and should be prepared.
PepsiCo:
Biggest maker of soft drinks PepsiCo comes first. A brief statement and a broader explanation make up this vision statement.
“BE THE GLOBAL LEADER IN CONVENIENT FOODS AND BEVERAGES BY WINNING WITH PURPOSE
This reflects our ambition to win sustainably in the marketplace and accelerate our top line growth, whilst keeping our commitment to do good for the planet and our communities. It builds on decades of progress we’ve made since PepsiCo was founded in 1965, while setting a firm foundation for a new era of growth and prosperity. To help us achieve this vision, we’ve defined a new set of aspirations: to become Faster, Stronger, and Better.” – PepsiCo
LinkedIn and Tesla:
The next two sentences are more succinct and obvious. They each consist of a single sentence that expresses the company’s future vision and shows how little writing is necessary for your idea to be understood.
LinkedIn:
“Create economic opportunity for every member of the global workforce.” – LinkedIn
Tesla:
“To accelerate the world’s transition to sustainable energy.” – Tesla
Project Vision Statement
The best vision statement format to use when discussing project vision statements is this: (Action) a (deliverable) that (criteria). Create (action) a furniture catalog that informs and attracts new customers (criteria) could serve as an illustration of this. Here are a few additional illustrations from Robert B. Sowby:
“Take to market a copier that is small, inexpensive, and reliable enough for personal use on a secretary’s desk.”
“Design an onboarding program that quickly transforms new employees into valuable long-term contributors.”
“Prepare a prioritized list of low-cost engineering recommendations that guides the organization to more energy-efficient operations.”
Another outstanding example Robert uses in his piece comes from none other than Boeing. It discusses the 777 program’s goals as well as the capabilities of their flagship aircraft. The following is the project’s vision statement:
“Denver to Honolulu on a hot day.” – Boeing 777
For Boeing employees, this is a fantastic project vision statement that gives direction without interfering with how this direction is attained, even though it may mean very nothing to an outsider. Additionally, it describes particulars like the length and weather of the flight. The team now has all the information they require about the final result.
You must come up with a vision statement that directly speaks to and resonates with your team if you want to succeed. Something as straightforward as “Provide business X with a project management solution that satisfies the needs of an engineering team” could be the request. Or something more detailed like PepsiCo’s vision statement.
The most crucial thing to remember is that the project team must comprehend and support the project vision statement in order for it to be effective.
Project vision in Agile
Agile projects, like projects using any other methodology, benefit from having a clear project vision statement. No matter which side of the Kanban vs. Scrum argument you are on, it should be done. The project’s initial writing establishes the project’s vision definition, which serves as the project’s guiding principle. This statement in Kanban was developed in consultation with the entire team and the key stakeholders. While in Scrum, the Product Owner and the stakeholders are responsible for defining the objectives and subsequently the vision.
Agile teams follow the same guidelines for creating vision statements as any other team. To create a statement that directs your team toward the desired outcome, you must consider the product goals, customers, and their needs. The ability to always have the project vision statement visible is one advantage of Agile, which is a visually driven project management method based on the task board.
2. Identify Scrum Master and Stakeholders
What is stakeholder in scrum?
Stakeholders are individuals or organizational units that frequently communicate with the product owner, scrum master, and scrum team in order to offer them feedback and promote the development of the project’s goods and services, affecting the project throughout its lifecycle. Stakeholders frequently include clients, users, and sponsors.
• Customer: The person or business that purchases the project’s goods and services. Depending on the project, every organization may have both internal (inside the same company) and external (within the organization) consumers.
• User: A person or a company who directly utilizes the project’s goods and services. There may be internal and external users for any firm, just like there may be customers. Users and customers might be the same depending on the project.
• Sponsor: A person or group that contributes funds and other resources to the initiative. The stakeholder to whom everyone ultimately answers is the sponsor.
Multiple stakeholder responsibilities can occasionally be played by the same individual or organization. For instance, Peter serves as both the customer and the sponsor.
Any project must choose the right Scrum Master(s) and identify the right stakeholders if it is to succeed. There may have been requirements for specific team members and their duties in some projects.
The following are crucial Selection Criteria to consider while choosing Scrum Masters:
1. Problem-solving skills – This is one of the most important factors to take into account when choosing Scrum Masters. To help the Scrum Team overcome any obstacles, the Scrum Masters should be equipped with the appropriate knowledge and expertise.
2. Availability – The Scrum Master must be accessible to plan, direct, and lead a variety of meetings, including the Release Planning Meeting, Daily Standup Meeting, and other Sprint-related meetings.
3. Commitment – The Scrum Master must be fully committed to creating a productive atmosphere for the Scrum Team in order to successfully complete Scrum projects.
4. Servant Leadership Style – A servant-leader puts others before themselves. It starts with the instinctive desire to serve first and foremost. The effort made by the servant-first to ensure that other people’s highest priority needs are met makes a difference.
It’s crucial to keep in mind that stakeholders are all the clients, users, and sponsors who constantly communicate with the product owner, scrum master, and scrum team to offer suggestions and aid in the production of the project’s deliverables. Throughout the course of the project, the stakeholders have an impact.
In one case study, a large software development company used a variety of techniques to identify their scrum stakeholders. They started by creating a list of all potential stakeholders, including internal and external groups. They then used surveys, interviews, and focus groups to gather feedback from these stakeholders and determine their needs and priorities. They also created a stakeholder map to visualize the relationships between different groups and identify potential conflicts. By taking a comprehensive approach to stakeholder identification, the company was able to create a more effective scrum process that met the needs of all stakeholders.
3. Form your Scrum Team
The process of creating a Scrum Team is only one more step in the Scrum Project. It belongs to the group of 6 processes in the initiating phase. Members of the Scrum Team are identified during this procedure. Although the Scrum Master and Product Owner frequently work together, the Product Owner is typically in charge of choosing the team members.
Choosing the correct team members is crucial for the successful completion of Scrum projects because the Scrum Team is the foundation of any Scrum project. Members of the Scrum Team are generalists-specialists since they are knowledgeable in a variety of subjects and authorities in at least one of them.
Self-organizing teams succeed or fail based on the soft skills of the team members, not only their subject-matter knowledge.
Independent, self-motivated, customer-focused, accountable, and collaborative individuals are the best Scrum Team members. To get the most out of the structure, the team should be able to establish a culture of autonomous thought and group decision-making.
The Scrum Team, also known as the Development Team, is a team of individuals tasked with comprehending the business requirements laid forth by the Product Owner, estimating User Stories, and producing the project Deliverables in its whole.
Cross-functional and self-organizing Scrum Teams. The quantity of work to commit to during a Sprint is decided by the team, along with the most effective method of completion. The Scrum Team is made up of cross-functional team members that perform all tasks necessary to produce deliverables that could be shipped, such as development, testing, quality assurance, etc.
The Product Owner is in charge of choosing the Scrum Team, frequently in cooperation with the Scrum Master.
Team Building Plan
Each member of a Scrum Team must actively contribute in every facet of the project because the team is cross-functional. To keep a productive team, the scrum master must diligently track down and resolve team member problems.
The Scrum Master should make sure that the team members have positive working relationships and are united in attaining the overall project and organizational goals to foster team cohesiveness, which will boost productivity and efficiency.
Facebook’s world-class Scrum Team
Facebook’s adoption of scrum to construct its social media platform is among the best examples of the methodology.
The business employs scrum to build its internal workings as well as its code.
One of the most widely utilized waterfall software development techniques was developed by one of the most well-known social networks in the world, Facebook. Their elite scrum crew is the reason they are always changing. One of Facebook’s policies, for instance, is the “Two-Pizza team,” which states that no matter how big a team is, it can never be larger than two pizzas. The business and its employees gain certain advantages from this.
4. Develop Epic(s)
An epic is a feature or functionality made up of numerous scenarios and building components. User stories are smaller segments of epics that can be divided into smaller segments based on topics or initiatives.
Multiple sprints, teams, and even projects may be involved in an epic. At various levels of the focus area, the epic, theme, and user stories all have the same strategic objective.
Think about the construction of a house as an example. If a user story is like building a wall with each brick representing a task, then an epic is like building a kitchen, and an initiative is like constructing the first floor.
Source: www.blog.logrocket.com
A large product vision is broken down into manageable, incremental tasks that result in often updated results via agile development.
The product development lifecycle can seem intimidating, much like building a house. Everyone working on the product might not be able to see where to begin. However, it can be helpful to divide the bigger project into different topics, like laying the groundwork and building the first level.
You can further divide it into epics, such as creating each room, and even further yet to building a wall. This helps us see more clearly what we need to accomplish right away in order to significantly advance the strategic endeavor.
Epics assist everyone in large organizations when multiple cross-functional teams are involved in product development in agreeing on development goals, dependencies, and priorities.
Epics vs. user stories vs. initiatives
The size of initiatives, themes, and epics can vary depending on the complexity of the product and the size of the organization. Smaller businesses or goods might simply have one hierarchy at the top. The fundamental concept remains the same, nevertheless, if the scale design is applied to an organization as a whole.
A product roadmap consists of more manageable, shorter activities. Every product development cycle includes many features that address consumer needs in parallel. However, that does not imply that at the time of introduction, the product must have undergone full development and contain all of its features.
Agile development places a strong emphasis on learning by doing and speedy delivery. The product development lifecycle from ideation to execution is sped up by breaking the topic into different stages.
By dividing the effort into more manageable minimal viable products (MVPs), this segmentation aids in prioritization. The team may learn and iterate, validate concepts, and alter the roadmap as necessary by quickly developing and launching the MVPs to the user.
Source: Atlassian
Regardless of how you structure the hierarchy structure of themes/initiatives, epics, and user stories, each level is defined with a purpose.
Themes and initiatives
Themes and initiatives define the product vision. The big idea is segmented into strategic goals.
Source: Atlassian
The theme’s role is to serve as the organization’s North Star by outlining the main areas of concentration for the whole thing.
The project may involve innovation, market fit, addressing a pain point, or closing a gap in the market.
Epics
The actualization of the product roadmap is an epic. The initiative is divided into identified features that need to be developed.
When it comes to prioritization, epics bring the organization and the product development together.
User stories
A user story is user-focused and driven by user value.
Although internal to the organization, the product strategy and roadmap, development should always be entirely user-centric. User stories aid the development team in understanding the user and elucidating the value the product generates from the viewpoint of the user.
How to write an epic
A feature must meet high-level requirements, such as an epic. To connect stakeholders with your product vision and roadmap, you should write epics. You should present all pertinent facts, including any dependencies, clear up any ambiguities, and define a clear path with a quantifiable goal in order to accomplish that alignment with clarity and focus.
An effective epic description requires cooperation. Although the product manager is in charge of creating an epic specification, they are not need to be an expert on every subject. Work together with your team to discuss and agree upon solution design, UX design, and the customer journey when building an epic spec document. To prevent getting stuck later, bring in the necessary knowledge and skills as soon as possible.
What to include in an epic
Because each development is unique, each product’s epic specifications will be different. While some epics outline high-level requirements merely, others go into great depth.
In order to get started on user stories and prioritize tasks to meet the demands of the client as effectively as possible, the product team should have the absolute minimum of information in an epic.
A basic epic is structured as follows:
1. Introduction
2. Product requirements
3. Engineering requirements
4. Design requirements
5. KPI metrics
Introduction
The “why” and “what” of prioritizing and developing the feature and user pain points to address should be explained in the introduction. The measures and KPIs for gauging performance should also be included.
Additionally, any early wireframes or documentation you can offer will greatly aid in creating a shared understanding of the objective and the best method to achieve it. Several points to think about:
• Summary of features and reasons for developing them
• Performance metrics and KPIs
• Links to specific documentation
• Marketing plans and legal requirements (if any)
• Early wireframes
Product requirements
Creating a common understanding of the growth aim is a crucial goal of the epic. The functional and nonfunctional needs for the feature should both be included in the epic.
There may be information on availability in several languages or across various devices in the product requirements documentation.
Design requirements
To write the design requirement, you should always work with the UX designer. They are the experts, and they will undoubtedly be able to impart knowledge gained from their extensive user test experiences.
Examples of product design requirements might include things like:
• Where to place search functionality for each device
• A request for a prototype to simplify future group discussions
Engineering requirements
When assembling the high-level requirements in an epic, you should work to align them with the desired architecture. Early consideration can help you estimate more accurately and maximize efficiency later on, just like the tech stack or solution design.
For illustration, suppose the engineering team wishes to develop an API to interface with some database capability already in place to retrieve a list of music. You may prevent unintentionally accruing technical debt by looking into these chances when you are still in the early stages of developing the epic.
KPI and metrics
Every phase of product development is guided by KPIs. The teams will be more focused and driven to achieve their goals if they have a clear set of metrics and targets.
KPIs ought to be observable and quantifiable. A nebulous KPI is useless and does not spur action. Some KPIs may not appear to be quantifiable at first, but after working with data analysts, it is always possible to quantify the worth of progress.
Increasing customer happiness is an excellent KPI but can be a little ambiguous, for instance. Instead, try using metrics like net promoter score (NPS) or how many times a user uses a new feature in a single session.
A real-world example of an epic
Let’s use a music streaming platform as an example to show how an epic is organized. Let’s say you wish to give the app search capabilities. A significant differentiator for your product, the database has more than 1 million songs from around the world, therefore it is essential that users can easily find the music they’re seeking for using the search capability.
Using the epic template below, our epic would look something like this:
Source: LogRocket
5. Create Prioritized Product Backlog
Scrum’s agile product backlog is a prioritized features list that includes succinct summaries of every feature that the product is intended to have. It is not required to begin a project with a time-consuming, upfront effort to document all requirements while using Scrum. Typically, the product owner and the Scrum team start by jotting down every idea they have for the agile backlog prioritization. For a first sprint, this agile product backlog nearly usually provides more than enough work. The Scrum product backlog is then permitted to expand and modify when new information about the product and its users becomes available.
A typical Scrum backlog comprises the following different types of items:
1. Features
2. Bugs
3. Technical work
4. Knowledge acquisition
User stories, which are brief, straightforward descriptions of the desired functionality told from the perspective of the user, are by far the most common approach for a Scrum team to describe features on the agile product backlog. As a consumer, I can review the products in my shopping basket before checking out so that I can see what I’ve previously chosen, as an example.
Bugs are likewise added to the Scrum product backlog because there isn’t much difference between them and new features—each expresses a different user need.
The agile backlog should also include tasks involving technical work and knowledge acquisition. Technical work can include upgrading all developer workstations to Windows 7. A Scrum backlog item about comparing multiple JavaScript libraries and choosing one could serve as an illustration of knowledge acquisition.
The prioritized agile product backlog is brought by the product owner to the sprint planning meeting, where they go over the most important items with the team. Next, the team decides which tasks they can finish in the upcoming sprint. After that, the team adds things to the sprint backlog from the product backlog. In order to more effectively share work throughout the sprint, they do this by expanding each item on the Scrum product backlog into one or more sprint backlog tasks.
The team conceptually draws a line after the lowest high-priority item they believe they can complete after starting at the top of the prioritized Scrum queue. In actual fact, it’s not rare to see a team choose the top five items, followed by two items from the bottom of the list that are related to the first five.
Xebia used the scrum framework to create a more collaborative and iterative development process. They started by setting up a product backlog and creating a sprint backlog for each iteration. They also established a cross-functional team and held daily stand-up meetings to ensure everyone was on the same page. Overall, their adoption of scrum helped them to improve their development process and deliver better results.
6. Conduct Release Planning
As the Product Owner, Delivery Team (Core Agile Team, Network, Security, Operations, etc.), and Stakeholders collaborate and agree to a strategy for delivering a product increment by a specified date, the Scrum Master supports during Release Planning. While the Delivery Team offers insightful information on the technical viability, known velocity, and dependencies, the Product Owner communicates the product vision, commercial objectives, and prioritized backlog.
Release planning gives the Delivery Team, Product Owner, and Stakeholders the chance to agree on what needs to be accomplished (scope) and when (date), taking into account the resources (budget) that are available. Through the creation of a platform for cross-functional collaboration, participants are able to recognize cross-team dependencies that guide decision-making in accordance with capacity and readily available skill sets regarding the order of work.
Preparing for Release Planning
Consider the logistics of the entire Delivery Team while planning for Release Planning; make sure the room size and/or breakout rooms can accommodate the full number of attendees; and plan online video conferencing for team members who are dispersed. Be sensitive while coordinating across time zones and working hours, especially with remote team members. Use other communication channels (like Slack) and make sure team members have access to any tools, programs, or files that will enable them to actively participate and contribute throughout the session.
Additionally, make an agenda in advance to ensure that team members are ready for the discussion and that it stays focused on the targeted release(s). Planning for attendance and participation from leadership and (important) stakeholders should be done with an eye toward reducing dependencies that can hinder the team’s success. The entire cross-functional Delivery Team should be present for smaller teams in order to provide input and ensure accountability. A smaller group of team members may, however, be chosen to represent the Team for release planning on bigger teams.
The “Definition of Ready (DoR)” and baseline for sizing estimations of Backlog items should be used by the Delivery Team as they plan the release(s) (this is normally developed by the Agile Team prior to the start of development). By using this metric, user stories may be scheduled to be assigned to different sprints and to set size restrictions for the various release dates, which typically last between two and twelve months.
Course Manual 5: Planning & Estimates Phase
During the Sprint Planning Meeting, the entire team estimates in Scrum projects. The goal of the estimation would be to prioritize the User Stories for the Sprint and assess the team’s capacity to complete them inside the Sprint’s Time Box.
The prioritized User Stories are moved to the top of the Product Backlog by the Product Owner, who also makes sure they are clear and can be estimated.
The Scrum Team will take care to choose the User Stories for the Sprint based on the size of the Product Increment and the effort necessary for the same, as the Scrum Team as a whole is accountable for the delivery of the product increment.
User Story Points are used to estimate the size of the product increment. Once the size has been established, the effort is approximated using historical data, or effort per User Story Point, otherwise known as Productivity.
User Stories
User stories are a component of an agile methodology that aids in moving the emphasis away from writing about requirements and toward discussing them. Every agile user story has one or two written sentences, but its primary purpose is to start a discussion about the features and functionality it represents.
The expected functionality of product backlog items is expressed in user stories. User stories with a higher priority tend to be more thorough than those with a lower priority. As stories become more important, teams add details by either developing acceptance criteria or by dividing large tales into smaller ones (or both). Continue reading to learn more about user stories, the user story framework, and to see some user story examples.
What is a user story?
A user story is a short, simple description of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system. User stories typically follow a simple template:
As a *type of user*, I want *some goal* so that *some reason*
User stories have traditionally been written on index cards or sticky notes, maintained in a shoe box, and placed on walls or tables to assist planning and debate. As more was discovered about the product being created, it was simple to disassemble, discard, and replace them with fresh tales due to their transience.
User stories can now be kept in a Jira issue or a Trello board just as simply. Do not be less inclined to eliminate user stories when they are no longer required just because they are included in a tool.
The goal of user stories is to significantly shift the emphasis away from writing about features and toward discussing them. In actuality, the dialogues are more significant than any written material.
What Is a Good User Story?
Three components make up agile user stories, which Ron Jeffries identified in 2001 using the lovely alliteration of “card,” “conversation,” and “confirmation”:
1. Card: Written description of the story, used for planning and as a reminder
2. Conversation: Conversations about the story that serve to flesh out the details of the story
3. Confirmation: Tests that convey and document details that can be used to determine when a story is complete.
Although user stories have several benefits, the most crucial one might be that each one serves as a placeholder for a later conversation.
How to write a user story
Understanding the fundamental user story template, keeping the user or customer in mind, and having a clear idea of the desired functionality are all necessary for writing effective user stories in Scrum.
User Story Template
When writing a user story, remember that user stories follow a standard template:
As a *type of user*, I want *some goal* so that *some reason*
Examples of User Stories
Seeing examples is one of the best methods to understand how to develop a user narrative for an agile project. Here are a couple of examples of user stories. Here are a few actual instances of user stories that outline the intended features of a prototype Scrum Alliance website.
• I can apply as a site member to become a Certified Scrum Trainer, which will allow me to certify others and teach Certified Scrum Master (CSM) and Certified Scrum Product Owner (CSPO) courses.
• In order for potential students to find my courses, I as a trainer want my profile to show all of my future classes and give a link to a thorough page about each.
• I can access old news as a site visitor, so I can retrieve anything I recall from the past or those others have mentioned to me.
• As a site visitor, I may view a list of all forthcoming “Certification Courses” and, if there are several, page through them to choose the one that’s right for me.
The user story “As a product owner, I want a list of certification courses so that…” is missing, as you will notice. The product owner is a crucial stakeholder, but they are not the customers or end users. It’s best to be as detailed as you can regarding the kind of user when drafting user stories.
Who writes user stories?
Who writes user stories? Anyone can write user stories.
Does the product owner write user stories?
Although it is the product owner’s duty to ensure that an agile user story product backlog exists, this does not imply that the product owner is also responsible for writing the user stories. You should anticipate that each team member will write user stories during a successful agile project.
Also, keep in mind that who contributes to a user story’s discussion is significantly more crucial than who actually writes it.
When are user stories written?
Every stage of an agile project involves writing user stories. A story-writing workshop is typically held right at the beginning of an agile project. With the aim of developing a product backlog that completely outlines the functionality to be added over the length of the project or a three to six-month release cycle within it, the entire team participates.
Undoubtedly, some of these agile user stories will be epics. Later, epics will be divided into smaller storylines that can be completed in a single cycle. In addition, anyone and at any moment can write new stories and add them to the product backlog.
Can you show other user story examples?
These typical user stories for a job posting and search website serve as a more general illustration of how to write user stories in Scrum:
• A user can post her resume to the web site.
• A user can search for jobs.
• A company can post new job openings.
• A user can limit who can see her résumé.
Examples of Epics
The flexibility of writing agile user stories at different degrees of detail is one of its advantages. A user story can be written to encompass a big amount of functionality or just one particular, minor feature.
Large user stories are less detailed, and are generally known as epics.
Here is an epic agile user story example from a desktop backup product:
• I can backup my full hard drive as a user. An epic is typically too big for an agile team to finish in one iteration, thus it is first divided into several smaller user stories. The aforementioned epic could be divided into dozens, if not hundreds, of user stories, like these two examples below:
• As a power user, I may choose which files or folders to back up depending on the size, creation, and modification dates of the files.
• I can choose which folders to not backup as a user to prevent my backup drive from becoming clogged with unnecessary data.
How is detail added to user stories?
Detail can be added to user stories in two ways:
• By splitting a user story into multiple, smaller user stories.
• By adding conditions of satisfaction (acceptance criteria).
It is normal to presume that detail has been added when a very large story is broken up into numerous, smaller agile user stories. There has, after all, been more writing.
A high-level acceptance test that will hold true once the agile user story is finished is all that the requirements of satisfaction are. Another example of an agile user story is the one that follows:
As vice president of marketing, I’d like to choose a holiday season to compare the effectiveness of previous ad campaigns to in order to find the most successful ones.
The following requirements of satisfaction could be added to that user narrative example to provide more detail:
• Ensure that it is compatible with the following significant shopping holidays: Christmas, Easter, President’s Day, Mother’s Day, Father’s Day, Labor Day, and New Year’s Day.
• Support holidays that span two calendar years (none span three).
• You can designate a period of time between one festival and the next (for example, from Thanksgiving to Christmas).
• The start of the holiday season can be specified to be a certain number of days beforehand.
Do user stories replace a requirements document?
A product backlog, which is a prioritized list of the functionality to be built in a product or service, is used in agile projects, particularly Scrum projects. Although the team may choose any type of item for the product backlog, user stories have become the best and most common type.
Although a product backlog might be seen as a replacement for a traditional project’s requirements document, it’s crucial to keep in mind that an agile user story’s written portion (“As a user, I want…”) is incomplete until the debate about that story takes place.
The textual portion is frequently better viewed as a hint to the actual requirement. User stories may refer to any artifact that the product owner or team chooses, such as a workflow diagram, a calculation formula spreadsheet, or other document.
What are story points?
Consider the last time you traveled by car. Did it take as long as you anticipated or did you encounter unforeseen delays, such as traffic jams? Project planning and estimation might resemble that a lot. Unexpected challenges and project uncertainty might extend the timetable for your project and cause scope creep. Additionally, just like while driving, you can find yourself in unexpected situations, such as being over-budget and performing below expectations.
Here are some estimating strategies. You may precisely scope activities using estimating approaches like narrative points, which will give you and your team a better understanding of how much work tasks will entail and where problems could arise. Let’s explore the advantages of story points and their use.
What are story points?
Using story points, you can calculate how much work it will take to finish each user story in your product backlog. Since your team decides how much work they can complete at a sprint planning meeting, you’ll typically estimate story points prior to the meeting.
Three aspects that can affect a task’s scope and effort are typically taken into account by narrative points, and the value of the story point rises as a result. Story points are relative, therefore you determine their worth by taking into account these specifics and contrasting related actions.
• Risk is the overall risk or degree of uncertainty related to the task. The risk can grow, for instance, if the task involves contractors, stakeholders, or third parties.
• The team’s familiarity with comparable jobs is repetition.
• Task complexity is the degree of difficulty (and the degree of clarity of the task’s objectives).
Story points are relative, which means that their ratios to one another and relative value, rather than their exact numerical value, are what matter.
Story points vs. time-based estimation
Why not just use time as an estimate for tasks, you may be wondering. And you’re not mistaken: estimating work based on time (or hours) is a common practice.
However, there is a drawback: in contrast to story points, time-based estimations fail to take complexity, risk, or uncertainty into consideration. They also depend on each team member’s individual assessment, which varies according to seniority, comprehension of the assignment, and prior experience with projects of a similar nature.
These potential problems are resolved by story points, which promote cooperation and take risk, complexity, and experience into account. The end result is a common scoring scheme that maintains team cohesion.
Six steps to estimate story points
Now that you know what story points are, let’s go over how you can estimate them to scope user stories.
1. Introduce story points to your team
Success requires a thorough comprehension of story points. Walk your team through the fundamentals and advantages of narrative points to ease them into the process. Make sure in particular that they get the requirement for the tale point totals to scale in relation to one another.
Remember that ratios—not exact numbers—are what count for earning tale points. Or to put it another way, a task with a story point of two should require double the effort of a task with a story point of one. A task with a story point of three should require 1.5 times as much work as a task with a story point of 2. You can see where this is going.
2. Determine your story point sequence
Next, choose the order of your story’s points. In your estimation meeting, your team will utilize this system to score the stories (more on that later). Sequences are advantageous because they let your team concentrate on the relative sizes of the numbers, which simplifies the estimation of challenging tasks. What order of story points should you employ then? Agile estimation frequently uses the Fibonacci sequence, a set of integers where each number is the sum of the two numbers before it. But things can get challenging. Try t-shirt sizes if numerical quantities overwhelm your team. This order, as its name implies, divides activities into more manageable proportions based on the sizes of t-shirts: XS, S, M, L, XL, and XXL.
Tip: When estimating in Agile, teams typically change the Fibonacci sequence to 0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100 for ease of use.
3. Create a story point matrix
The story point sequence is essentially expanded upon in a story point matrix. It provides a starting point for your estimating meeting and clarifies for your team how to rate each assignment. We advise leveraging your understanding of the tasks your team regularly completes and the complexity, uncertainty, and effort involved with them if you haven’t utilized story points before.
Source: Asana
As you can see, story point values increase as the task’s effort, complexity, and risk increases.
Advice: As you conduct sprints and develop a greater grasp of the effort involved with your team’s duties, your narrative point matrix will change. Build off of your team’s regular tasks instead of worrying about getting it perfect the first time; instead, aim to reassess the matrix after each sprint.
4. Hold a planning poker meeting
It’s time to get to the heart of the matter: estimating your story points using a planning poker meeting, now that you’ve decided on your story point sequence and made your story point matrix.
Assigning story points to user stories, getting your team on the same page, and developing a notion of how many tasks your team can finish in the forthcoming sprint are the objectives of planning poker. This is accomplished by letting everyone comment on impending tasks at planning poker. When the entire team participates, you can be certain that you’re allocating tale points based on a variety of viewpoints and avoiding unconscious prejudices.
Here’s how to conduct a productive planning poker session.
1. Provide your team with a clearly defined story point matrix for reference and a deck of cards outlining your story point hierarchy. You can download a set of cards or make your own.
2. Decide on a user story.
3. Talk about the story with your team, including the issues involved and what constitutes success.
4. Allow each team member to choose in private the story point card they believe best captures the amount of work necessary to finish the narrative.
5. Have everyone on your team show their chosen cards simultaneously. The next user narrative should be tackled if the story points line up. If the story points don’t line up, talk about the user story again until you do.
6. Continue the procedure until all of the items in your product backlog have been given story points.
7. Calculate the number of tasks your team can do during the forthcoming sprint using the data from your narrative point matrix as a baseline.
Planning poker sessions should be scheduled for after your team has prioritized the backlog and before the start of your sprint. Planning a poker game can take anywhere from two to four hours (and your first session will probably take longer).
5. Plan and execute your sprint
If you’re using narrative points for the first time, you won’t know exactly how many you can finish in a sprint (also known as “sprint velocity”) until you’ve finished the first full sprint. That’s alright. Use your best judgment to determine how many story points to include in your sprint based on the difficulty of the tasks and the story point value in your sprint planning meeting.
Tip: Your initial sprint may have a large proportion of low-value story points, a small proportion of high-value story points, or a combination of both. You’ll discover over time what works best for your team and refine the procedure depending on input from your team.
6. Improve your story point estimations based on previous estimations
After you’ve finished your first sprint utilizing story points, it’s time to concentrate on continuous improvement, which is a keystone of the Agile methodology. To do this, gather your team and talk about what went well and what could be improved. This can either be discussed separately or as part of your sprint retrospective.
Ask your team whether the story points were properly scoped, about any unforeseen project bottlenecks they ran into, and about any additional reasons that the targets weren’t met. Utilize the solutions to tweak the procedure for the subsequent sprint. Reassess either your story point matrix or sequence as necessary.
How to use story points in Agile
There is no denying the need of preparation while managing projects. Missed deadlines, scope creep, and project failure can result from improper task scoping and scheduling. But if that scares you, don’t worry. Story points may be useful.
Let’s look at how to use story points within the Agile framework to gain a better understanding of them:
• First, write a user story for each desired feature. User stories follow the format “As a [persona], I want to [goal], so that [result or benefit].”
• Add your user stories to your product backlog.
• Assign story points to each user story to estimate effort.
• Use story points to select user stories from your backlog, ensuring you’re picking the right “amount” of work for each sprint.
• Execute your sprint.
Consider the following example: “As a user, I want to be able to submit feedback and questions through the site to better understand product features.” This user tale would be given a story point, again based on the amount of work you believe is necessary to finish it. The story can then be divided into smaller jobs, such as defining the feedback form’s scope and designing it, creating the form’s code, staging the page and testing the form, and publishing the page.
Advantages of using story points
Story points are the MVP of estimate methodologies for a reason—they make effort estimation simple and streamline sprint planning. That’s not all, though. A few more advantages of using story points are as follows:
• Promote quicker planning. Story points are relative, therefore you determine the worth of one by comparing it to previously determined, comparable values. A major advantage for your team is that using a relative scoring technique makes estimating faster over time.
• Take unpredictability and risk into account. Story points take into account variables like danger and unpredictability. By including these elements in your planning, you may more precisely scope out the task and eliminate estimation uncertainty.
• Get your team on the same page and stop planning with a bias based on skill sets. It’s not always a good idea to rely on individual team members’ estimates. After all, a senior team member is likely to estimate the effort pretty differently from a junior team member. Story points avoid these problems by promoting teamwork through planning poker meetings.
• Establish meaningful deadlines. Everyone dislikes arbitrary deadlines, yet when you utilize alternative estimation methodologies, you frequently end up with them. Story points produce relevant due dates since they are more complex.
• Build better estimations going forward. The adaptability and reusability of story points is one of their main advantages. That implies you may utilize your learnings to review your initial story point values and develop more precise estimations after creating a story point matrix and holding your first sprint.
Five story point pitfalls, plus how to avoid them
Story Point Land is not without its challenges. When used correctly, story points can speed the project management process, but only if you don’t make certain estimation mistakes. Here are some frequent estimation errors that teams make and advice on how to fix them.
• Using story points that aren’t relative. Because story points are relative, it’s simpler for your team to grasp how different activities stack up against one another. Because of this, you shouldn’t just randomly distribute points. Keep in mind that plot points should scale in relation to one another.
• Using hours for your story points. Using hour or day estimates as your story points defeats their purpose because time estimation ignores elements like complexity and unpredictability. Instead, consider the intricacy, risk, and recurrence of your story when calculating its point values.
• Taking the average of your team’s scores when planning poker. Don’t use the average of the points if your team’s estimates of the tale points differ from one another. Open the floor instead and talk about the difference. Finding a story point that everyone can agree upon is possible if you have a deeper grasp of why the estimations are out of sync.
• Assigning story points to user stories that are too large. Every event does not require a story point. It might be worthwhile to break down a user story further if you feel that none of the story point values in your matrix adequately reflect the work required.
• Failing to clarify expectations with team members about story point values. They are useless if your team doesn’t comprehend the story aspects. Fortunately, there is a simple fix: discuss the estimation process with your team. To ensure that they award story points correctly, walk them through an example story point matrix and have a conversation about each assignment.
Identify Tasks
Dissecting User Stories
The idea that this is a team effort must be made clear right immediately is one thing. The developers are truly the ones best positioned to grasp what in terms of technical skills must be built, as well as the level of effort needed, even though the product owner is responsible for prioritizing the backlog and gathering needs from the business and the customers.
When dividing user stories into tasks, the following points should be taken into account:
• Don’t make your tasks too small. A task should, as a general rule, be something that can be completed in a single day, but not in a short period of time.
• Be very specific about tasks’ scopes. Don’t construct tasks with general descriptions like “Coding” or “Implementation” in the mistaken belief that the parent user narrative would provide all the information. Write something more profound that also clearly defines the scope. Develop the login class, for instance.
• As a starting point and checklist, respectively, use the user story’s acceptance criteria and its definition of done. The definition of done is a checklist for all user stories that can also assist you in determining whether you’re missing any tasks for the narrative to be done. The acceptance criteria will help you decide what features need to be implemented.
To make sense of everything, let’s walk through an example. Take the following user story, which was specified as a requirement for a web application:
I want to sign in with my username and password as a registered user so that the system can verify my identity and I can trust it.
And with the subsequent standards for acceptance:
“Given that I am a registered user and logged out…”
1. “The information related to my user should be accessible if I go to the log in page, enter my username and password, and click Log in.”
2. “…if I visit the log-in page, enter my username but an incorrect password, and click Log in, then log-in fails with an error message stating that the username or password was incorrect.”
3. “…if I go to the login page, enter my username and password, and click Log in, then my user login session is loaded in less than eight seconds.”
And let’s assume that the notion of “done” for all user stories encompasses making sure that the code follows style guidelines and standards and has been thoroughly tested.
When you gather all the developers to discuss the requirements, you might hear things like:
• “We need a new UI element for Sign-up and Login”
• “We need to develop encryption functionality for the password”
• “We need to create a table in the database for user information”
• etc.
Let’s ask ourselves (the team), in order to proceed in a more systematic manner:
1. How can we turn this into a series of manageable, task-specific actions? Here, the group may decide on the following user narrative tasks:
– Identify the style of the sign-up/login form and create a new CSS class
– Write the HTML and Javascript presentation layer code for sign-up and login.
– Develop the validation code for the Javascript sign-up form, etc.
2. Will all tasks be completed with the acceptance criteria met? The team considers the acceptance criteria in this case and draws the following conclusions:
– Without creating an error page or message, the second acceptance condition would not be satisfied. The team then adds an error message to the task’s scope (description), “Develop HTML and Javascript Sign-Up/Login presentation layer code.” An entirely new task would be inadequate for this.
– A non-functional criterion is mentioned in the third acceptance criterion. The team adds the task “Run performance tests on the login function” because it knows that without thorough testing it cannot be certain that the goal will be achieved.
3. Considering the tasks, can the user story be considered complete? Two further tasks should be added to this user story to assure its completion, the team determines after going through the checklist of criteria for determining whether a user story is complete:
– Develop and execute regression tests
– Updated change log to reflect new sign-up/login features.
By asking ourselves these questions, you can now notice that the task list has gotten a little longer. After completing this exercise several times, the team will logically begin to consider these issues at the outset and will get better each time at developing ancillary tasks, such as testing- or documentation-related ones, to guarantee that crucial details are never overlooked and delivery is accepted.
Salesforce success by breaking down their scrum tasks
Salesforce didn’t have a term for scrum when they first started implementing it. In order to improve their development process, they simply used the ideas. They were able to get more out of the product development process by visualizing their workflow in a physical place, reducing jobs into manageable pieces, and presenting their progress continuously.
You may improve your company’s overall performance by using scrum to track the progress of your team. Spend some time today in your company figuring out how to integrate scrum into your overall workflow.
Estimating Task Effort
It’s time to estimate work once you have a better understanding of the list of tasks that belong within each user story. Here, it’s crucial to take into account:
• Dependencies and downstream tasks: Does this job require the creation or modification of any dependents or structural components?
• Complexity and team skills: Do the developers possess the abilities required to do this task? Or will they require some time for study and research?
• Previous estimates: Can the developers use earlier estimates for comparable projects to more accurately gauge the current task’s effort? Has a similar action been taken before?
Update Sprint Backlog
In this process, the Scrum Core Team updates the Sprint Backlog with further details about the tasks as part of the Sprint Planning Meeting.
Source: www.knowledgehut.com
The tasks that the Scrum team expects to achieve during the sprint are included in the sprint backlog. The team chooses a certain number of product backlog items, typically in the form of user stories, and determines the tasks required to finish each user story during the sprint planning meeting. Most teams also provide an estimation of how many hours each task will require from a team member.
The team must decide on the contents and scope of the sprint backlog. They must be the ones to decide what they are committed to throughout the Scrum sprint because they are the ones who are committing to finishing the tasks.
Although a spreadsheet is frequently used to manage the sprint backlog, you can also utilize your defect tracking system or any of the numerous software tools made expressly for Scrum or agile. This is an illustration of a sprint backlog in a spreadsheet:
Source: mountaingoatsoftware.com
Team members are expected to update the sprint backlog at least once each day during the Scrum sprint as new information becomes available. This will be done by many teams during the daily scrum. The ScrumMaster computes and plots the projected amount of work left in the sprint once every day, producing a sprint burndown chart like this one.
While the team makes every effort to ensure that the Scrum sprint has the appropriate amount of work, sometimes too much or too little work is pulled in during planning. The team will need to add or eliminate tasks in this situation.
Source: mountaingoatsoftware.com
Let’s use the sprint burndown chart shown above as an illustration. As you can see, the team in this example brought in too much work at the beginning of the sprint, and on day 13 of a 20-day sprint, there were still around 600 hours left. After being discussed, the product owner approved the decision to drop a few user stories from the sprint. The significant decline on the chart between days 13 and 14 was the effect of this. The team continued to make steady progress after that and successfully completed the Scrum sprint.
Scrum Estimation Techniques
The difficulty level for each User Story is taken into account in the Scrum estimation process. Using a certain scale, the degree of difficulty is determined.
Scales of several kinds are employed in scrum estimation. Here are a few examples:
• Numeric Sizing (1 through 10)
• T-shirt Sizes (XS, S, M, L, XL XXL, XXXL)
• Fibonacci Sequence (1, 2, 3, 5, 8, 13, 21, 34, etc.)
• Dog Breeds (Chihuahua,………,Great Dane)
The estimation technique is normally chosen in such a way that the entire scrum team is acquainted and comfortable with scale’s values. The most commonly used and most popular technique is Planning Poker which is based on Fibonacci sequence.
Planning Poker Technique
Source: Visual Paradigm
Planning poker is used in the Planning Poker Estimation Technique to determine estimates for the User Stories. It involves the entire Scrum Team and produces speedy yet accurate estimates.
A deck of cards is used to play planning poker. The numbers on the cards correspond to the Fibonacci sequence: 1, 2, 3, 5, 8, 13, 21, 34, etc. The Story Points are represented by these numbers. A deck of cards is available to each estimator. When a team member holds up a card, the numbers on the card should be large enough for all team members to see.
As the Moderator, one team member is chosen. The estimator examines the User Story’s description that is the subject of the estimation. The Product Owner responds to the questions of the estimators.
Each estimator chooses a card to symbolize their estimate in private. Once every estimator has chosen, the cards are revealed. All cards are then simultaneously flipped over and held up so that each estimate is visible to every team member.
It is extremely possible that the estimates will differ in the initial round. The reasons for the high and low estimators’ estimates are given. It is important to remember that all discussions are aimed to promote understanding and that nothing should be interpreted personally. The same must be guaranteed by the moderator.
The group has a few more minutes to discuss the story and their estimates.
When the particular tale is developed, the moderator can make notes on the debate that will be useful. Each estimator re-estimates by picking a card after the conversation. Cards are once more kept secret until after everyone has estimated, at which moment they are all simultaneously flipped over.
Repeat this procedure until there is only one estimate left that may be used for the story. Depending on the user story, there may be different numbers of estimation rounds.
Benefits of Planning Poker Estimation
Planning poker combines three methods of estimation
Expert Opinion: In an Expert Opinion based Estimation approach, a question on the size or duration of an item is posed to an expert. The expert makes an estimate based on experience, intuition, or gut instinct.
Comparing expert opinion estimation to various analytical procedures, it typically takes less time and is more accurate.
Analogy: Analogy Estimation uses comparison of User Stories. The user story that is being estimated is contrasted with past versions of similar user stories. As a result, since the estimation is based on reliable facts, the findings are correct.
Disaggregation: Estimation is carried out by dividing a User Story into smaller, more manageable User Stories. The typical development time for the user stories that will be part of a sprint is between two and five days. Therefore, lengthier User Stories that may require more time must be divided into smaller Use Cases. Additionally, this strategy makes sure that many of the stories are comparable.
Planning Poker is a fun yet effective method for estimating. The team would find it simple to agree on implementation of the User Story at hand because the session is open for discussion before the final estimate is determined.
Nokia and IBM have both used planning poker to estimate the effort required for software development projects. By using planning poker, these companies were able to improve the accuracy of their estimates and better plan their development projects.
Course Manual 6: Sprint Planning Meeting
We have already discussed the estimation phase and how long your first sprint will be.
However, there is one crucial element to launch your first sprint—the sprint planning meeting—before any of it can happen.
You’re already halfway to achieving your sprint objective if you can ace your first planning meeting.
Come well-prepared
A successful sprint planning meeting starts with thorough preparation.
Without taking this first step, your developers will find the meeting to be unorganized, useless, and unproductive.
Setting the meeting day and time will be the first step. Imagine choosing whenever it is most convenient for you to accomplish this. There is a chance that important players won’t be available when you need them.
What happens if the product owner is away? What happens if your lead programmer has another meeting? The phase of the sprint that is perhaps the most important is the part from which decision-makers are excluded.
Therefore, be sure to set the meeting up for a time when everyone will be free.
We advise adhering to the following general recommendation when choosing the meeting slot’s duration:
Source: www.shakebugs.com
The planning meeting shouldn’t run longer than four hours if it involves a two-week sprint. In light of this, allocate the first half of the workday to discussing the specifics with your staff. Even though you might not require the full four hours, it is usually better to estimate too much than too little.
After securing a time for your meeting, you should create and disseminate your agenda. The agenda is essential to every meeting since it will help you stay on topic, handle all the concerns, and follow the agenda’s intended format.
There are many templates available to use as a starting point if you’ve never created an agenda in advance. Here’s an illustration:
Source: www.hugo.team
Start with this agenda and gradually modify it to best meet the requirements of your team. Include some time on your schedule to go over all of your story points, or estimations of how much work various jobs will entail.
As was mentioned, story points rank assignments according to how tough you anticipate them to be.
Source: Asana
As you can see, the simpler workload is denoted by a lower number, while the more difficult duties are denoted by a greater number. As it’s frequently the best way to estimate how much you’ll be able to do in a sprint, it’s critical to settle on the narrative points for jobs well in advance.
It could be a good idea to reduce the number of jobs you have or replace them with easier ones if they all end up being in the double digits.
Present the sprint goal
It’s time to start the meeting itself when you’ve finished all of your preparations.
Starting the sprint planning by presenting the goal itself is always a smart approach, just like in the example template from the previous section.
The sprint goal is defined as follows:
To put it another way, the sprint goal acts as a kind of beacon, a broad aim that your team works to accomplish by the conclusion of the sprint.
Your team should be more inclined to work together with this sprint objective in mind because everyone is conscious of the common goal they are all working toward.
Your developers should be encouraged by the group duty to collaborate and do their best work in order to both succeed and to aid the other team members in their endeavors.
The sprint objective also gives guidance. Your developers always have a reference point to serve as a reminder of their goals if they become uncertain at any time during the sprint.
The sprint target should always be presented before getting into the backlog items for this reason. Scrum.org’s CEO, Dave West, explains why:
Source: www.shakebugs.com
What tasks to do depends on the sprint goal. Despite the size of your backlog, what will enable you to meet the sprint target still takes priority. You might even come up with alternatives that eliminate some of the items on your backlog.
For illustration, suppose your sprint goal is to make it possible for associated devices to use a manual LED control screen, as opposed to merely an automatic one in the past.
In such case, it would be simple to build a sequence that makes use of the entire LED spectrum or add a program that lasts longer than 90 seconds to clear the backlog.
You won’t have to worry about the various automatic setting options with the new manual setup. Instead, the customer can explicitly select the software of their choice, in which case the items in your backlog will be eliminated. When choosing this sprint goal, we advise using the previously described SMART goal-setting process. The framework is as follows, for your reference:
The aforementioned characteristics will all be present in a SMART sprint goal. These traits offer the direction and specifics required while developing software; there is no opportunity for uncertainty.
A SMART goal may be, drawing on the prior illustration, “In one month, release manual controls for the full LED spectrum in our app-paired devices for a better user experience.” This SMART goal has an exact time definition, is extremely specific, and is attainable.
The developers have a clear sense of direction and know exactly what they’re aiming to accomplish with this methodology.
Discuss product backlog items
The discussion of the product backlog items follows the definition of the sprint goal. The product backlog is a thorough list of everything that will eventually need to be included in the product; it is never finished, never empty, and it is continuously evolving.
It’s crucial to order and select the tasks your team wants to finish within the sprint due to its broad scope.
You and your developers will need to decide which backlog items are most important and, thus, have the greatest priority during the sprint planning meeting. Don’t forget to have a look at the plot points as well, though. Your developers may be taking on too much if the total number of story points is too high. These items are transferred from the product backlog to the sprint backlog once you and the team have decided which features to concentrate on.
The product backlog includes all potential features, whereas the sprint backlog is just a list of things the team has committed to delivering during that sprint.
The contrast between the two is shown in the image below:
The sprint backlog, which is a subset of the product backlog as you can see above, contains a list of all the features that need to be finished during the sprint.
This helps your team decide on their tasks for that sprint.
It’s best to follow the DEEP concept for handling the product backlog:
Source: www.shakebugs.com
Consider whether the item contributes to the DEEP principle each time you consider adding it to the product backlog.
• Is the entry sufficiently thorough for all members of your team to understand?
• Have the story points been assigned? What level of importance is it?
Answer these questions before blindly posting new items.
Maintaining a DEEP backlog will greatly simplify your backlog discussions when the backlog improves.
Regularly discuss the product backlog with your developers and product owner.
Make sure to continuously revise the backlog; doing so will make future planning much more doable. This can be done two or three days prior to the end of the sprint or during the sprint planning meeting itself.
Estimate team velocity
After deciding which backlog items to prioritize, your team should evaluate their velocity.
As it dictates how much work your team will be able to complete during the sprint, this metric is one of the most important measurements used in sprint planning.
Scrum Inc defines team velocity as follows:
“Velocity is a measure of the amount of work a Team can tackle during a single Sprint and is the key metric in Scrum. Velocity is calculated at the end of the Sprint by totaling the Points for all fully completed User Stories.”
It will be difficult to estimate team velocity for your first sprint because it is best determined after your team has completed several sprints.
For future usage, the usual formula is the total number of user story points that have been completed divided by the total number of sprints that have been finished.
Imagine, for instance, that your team finished 25 story points in the first sprint, 30 in the second, and 35 in the third. The velocity is then determined as follows:
25+30+35=90/3=30
The total can then be used as a benchmark to gauge how much can be completed during subsequent sprints.
It’s also a great resource for figuring out how many things to pick up from the product backlog.
When you first start estimating, these numbers will probably fluctuate, but as your team completes more sprints, the amount will settle.
A research paper conducted a case study recently that confirmed these findings, stating:
Source: www.shakebugs.com
In other words, even if you initially become discouraged, don’t give up. It will eventually pay off if you persevere with the practice.
Furthermore, as your team expands and becomes accustomed to working together, the velocity will automatically rise. A dependable team is one that members are comfortable with.
The velocity of your team should never be compared to that of another team for the same reason. The speed of development is frequently determined solely by the compatibility of your developers, not by their technical proficiency or years of professional experience. Although you may be aware of teams with a higher velocity than your own, this does not necessarily indicate that your engineers are underperforming. Simply put, they move to a different rhythm.
Determine task ownership
Choosing task ownership is the final but crucial stage in a sprint planning meeting. You’ll need to decide who will handle what responsibilities and allocate tasks to your team members.
The use of a Scrum Board is among the simplest ways to accomplish this. A standard Scrum Board is often divided into four columns and serves as a visual tool to aid with sprint organization.
• To Do—the backlog items planned for the sprint
• In Progress—the items that you’ve started working on
• In Reviews—items that are being tested and reviewed
• Done—completed and verified items
Here’s an example Scrum Board:
Tasks are most easily distributed by breaking down the items in the sprint backlog. In other words, each sprint backlog item is achieved by completing various tasks.
The visual below explains the concept well:
Consider the scenario where allowing users to update shipment information was a sprint backlog item. Then, you can break that item down into actions like updating security tests, working with designers to sketch an app screen, updating the API for delivery, etc. These tasks should likewise be very particular, just as backlog items should be as specific as feasible.
Your developers will receive more direction from you if you give them more specific instructions, which will help them decide which jobs to tackle. Knowing exactly what the assignment entails greatly simplifies distribution.
It’s a good practice to let your developers review their assignments after allocating the duties to them before getting to work. They can then determine with a clear mind whether their duties are doable. Giving your developers some wiggle room between job assignments and the start of the work allows them to brainstorm first ideas and consider whether the task is a good fit for them.
There’s nothing to worry about if it turns out that they’d prefer not to take on a task or if they feel overwhelmed. You still have plenty of time to organize since the sprint has just begun.
Conclusion
A significant turning point for the sprint and your professional career is your very first sprint planning meeting. A quality planning meeting will allow you to do half of the sprint tasks.
Make sure you are prepared for the meeting and that you can clearly communicate the sprint goal to your developers.
Review the items in the product backlog and calculate your team’s velocity. Determine how many tasks they’ll complete.
And finally, assign the duties to the team members who have the most expertise. Your sprint planning meeting will go off without a hitch if you stick to these five guidelines.
Case Study
Here’s an example of a case study about a Scrum planning meeting:
A software development team at a medium-sized company was tasked with building a new e-commerce platform for a client. The team consisted of 6 developers, a Scrum Master, and a Product Owner.
During the first planning meeting, the team agreed on a Sprint goal: to build a fully functional shopping cart feature within 2 weeks. The Product Owner presented the user stories for the shopping cart feature, and the team estimated the effort required for each story using planning poker.
After the estimates were completed, the team agreed on which stories to include in the Sprint backlog. The Scrum Master then facilitated a discussion on how the team would approach the work, and the team decided to use pair programming and code reviews to ensure high-quality code.
The team also agreed to hold daily stand-up meetings to track progress and identify any obstacles. The Scrum Master reminded the team to focus on the Sprint goal and to communicate any changes or issues to the Product Owner.
At the end of the Sprint, the team had successfully built the shopping cart feature, and the client was pleased with the results. The team held a retrospective meeting to discuss what went well and what could be improved for the next Sprint.
This case study highlights the importance of effective planning and communication in Scrum, as well as the benefits of using techniques such as planning poker and pair programming to improve the quality of work.
Workshop Exercises
Implementing Scrum Exercises
01. Define your Scrum Team: Explain in your own words how this process will directly impact upon your department?
02. Scrum Master: Explain in your own words how this process will directly impact upon your department?
03. Product Owner: Explain in your own words how this process will directly impact upon your department?
04. Initiation Phase: Explain in your own words how this process will directly impact upon your department?
05. Planning & Estimates Phase: Explain in your own words how this process will directly impact upon your department?
06. Sprint Planning Meeting: Explain in your own words how this process will directly impact upon your department?
SWOT & MOST Analysis Exercises
01. Undertake a detailed SWOT Analysis in order to identify your department’s internal strengths and weaknesses and external opportunities and threats in relation to each of the 12 Implementing Scrum processes featured above. Undertake this task together with your department’s stakeholders in order to encourage collaborative evaluation.
02. Develop a detailed MOST Analysis in order to establish your department’s: Mission; Objectives; Strategies and Tasks in relation to Implementing Scrum . Undertake this task together with all of your department’s stakeholders in order to encourage collaborative evaluation.
Project Studies
Project Study (Part 1) – Customer Service
The Head of this Department is to provide a detailed report relating to the Implementing Scrum process that has been implemented within their department, together with all key stakeholders, as a result of conducting this workshop, incorporating process: planning; development; implementation; management; and review. Your process should feature the following 12 parts:
01. Define your Scrum Team
02. Scrum Master
03. Product Owner
04. Initiation Phase
05. Planning & Estimates Phase
06. Sprint Planning Meeting
Please include the results of the initial evaluation and assessment.
Project Study (Part 2) – E-Business
The Head of this Department is to provide a detailed report relating to the Implementing Scrum process that has been implemented within their department, together with all key stakeholders, as a result of conducting this workshop, incorporating process: planning; development; implementation; management; and review. Your process should feature the following 12 parts:
01. Define your Scrum Team
02. Scrum Master
03. Product Owner
04. Initiation Phase
05. Planning & Estimates Phase
06. Sprint Planning Meeting
Please include the results of the initial evaluation and assessment.
Project Study (Part 3) – Finance
The Head of this Department is to provide a detailed report relating to the Implementing Scrum process that has been implemented within their department, together with all key stakeholders, as a result of conducting this workshop, incorporating process: planning; development; implementation; management; and review. Your process should feature the following 12 parts:
01. Define your Scrum Team
02. Scrum Master
03. Product Owner
04. Initiation Phase
05. Planning & Estimates Phase
06. Sprint Planning Meeting
Please include the results of the initial evaluation and assessment.
Project Study (Part 4) – Globalization
The Head of this Department is to provide a detailed report relating to the Implementing Scrum process that has been implemented within their department, together with all key stakeholders, as a result of conducting this workshop, incorporating process: planning; development; implementation; management; and review. Your process should feature the following 12 parts:
01. Define your Scrum Team
02. Scrum Master
03. Product Owner
04. Initiation Phase
05. Planning & Estimates Phase
06. Sprint Planning Meeting
Please include the results of the initial evaluation and assessment.
Project Study (Part 5) – Human Resources
The Head of this Department is to provide a detailed report relating to the Implementing Scrum process that has been implemented within their department, together with all key stakeholders, as a result of conducting this workshop, incorporating process: planning; development; implementation; management; and review. Your process should feature the following 12 parts:
01. Define your Scrum Team
02. Scrum Master
03. Product Owner
04. Initiation Phase
05. Planning & Estimates Phase
06. Sprint Planning Meeting
Please include the results of the initial evaluation and assessment.
Project Study (Part 6) – Information Technology
The Head of this Department is to provide a detailed report relating to the Implementing Scrum process that has been implemented within their department, together with all key stakeholders, as a result of conducting this workshop, incorporating process: planning; development; implementation; management; and review. Your process should feature the following 12 parts:
01. Define your Scrum Team
02. Scrum Master
03. Product Owner
04. Initiation Phase
05. Planning & Estimates Phase
06. Sprint Planning Meeting
Please include the results of the initial evaluation and assessment.
Project Study (Part 7) – Legal
The Head of this Department is to provide a detailed report relating to the Implementing Scrum process that has been implemented within their department, together with all key stakeholders, as a result of conducting this workshop, incorporating process: planning; development; implementation; management; and review. Your process should feature the following 12 parts:
01. Define your Scrum Team
02. Scrum Master
03. Product Owner
04. Initiation Phase
05. Planning & Estimates Phase
06. Sprint Planning Meeting
Please include the results of the initial evaluation and assessment.
Project Study (Part 8) – Management
The Head of this Department is to provide a detailed report relating to the Implementing Scrum process that has been implemented within their department, together with all key stakeholders, as a result of conducting this workshop, incorporating process: planning; development; implementation; management; and review. Your process should feature the following 12 parts:
01. Define your Scrum Team
02. Scrum Master
03. Product Owner
04. Initiation Phase
05. Planning & Estimates Phase
06. Sprint Planning Meeting
Please include the results of the initial evaluation and assessment.
Project Study (Part 9) – Marketing
The Head of this Department is to provide a detailed report relating to the Implementing Scrum process that has been implemented within their department, together with all key stakeholders, as a result of conducting this workshop, incorporating process: planning; development; implementation; management; and review. Your process should feature the following 12 parts:
01. Define your Scrum Team
02. Scrum Master
03. Product Owner
04. Initiation Phase
05. Planning & Estimates Phase
06. Sprint Planning Meeting
Please include the results of the initial evaluation and assessment.
Project Study (Part 10) – Production
The Head of this Department is to provide a detailed report relating to the Implementing Scrum process that has been implemented within their department, together with all key stakeholders, as a result of conducting this workshop, incorporating process: planning; development; implementation; management; and review. Your process should feature the following 12 parts:
01. Define your Scrum Team
02. Scrum Master
03. Product Owner
04. Initiation Phase
05. Planning & Estimates Phase
06. Sprint Planning Meeting
Please include the results of the initial evaluation and assessment.
Project Study (Part 11) – Logistics
The Head of this Department is to provide a detailed report relating to the Implementing Scrum process that has been implemented within their department, together with all key stakeholders, as a result of conducting this workshop, incorporating process: planning; development; implementation; management; and review. Your process should feature the following 12 parts:
01. Define your Scrum Team
02. Scrum Master
03. Product Owner
04. Initiation Phase
05. Planning & Estimates Phase
06. Sprint Planning Meeting
Please include the results of the initial evaluation and assessment.
Project Study (Part 12) – Education
The Head of this Department is to provide a detailed report relating to the Implementing Scrum process that has been implemented within their department, together with all key stakeholders, as a result of conducting this workshop, incorporating process: planning; development; implementation; management; and review. Your process should feature the following 12 parts:
01. Define your Scrum Team
02. Scrum Master
03. Product Owner
04. Initiation Phase
05. Planning & Estimates Phase
06. Sprint Planning Meeting
Please include the results of the initial evaluation and assessment.
Program Benefits
Information Technology
- Agile IT processes
- Improved value delivery
- Decreased defects
- Continuous improvement
- Modernized infrastructure
- Re-tooled staff
- Increased morale
- IT Business partnership
- Meaningful metrics
- Effective sourcing
Management
- Decreased costs
- Aligned strategies
- Servant leadership
- Clarified priorities
- Improved effectiveness
- Improved transparency
- Reduced risk
- Measurable results
- Satisfied customers
- Vendor partnerships
Human Resources
- Empowered teams
- Servant leaders
- Re-tooled staff
- Improved teamwork
- Enhanced collaboration
- Improved performance
- Reduced turnover
- Improved loyalty
- Leadership development
- Employee development
Client Telephone Conference (CTC)
If you have any questions or if you would like to arrange a Client Telephone Conference (CTC) to discuss this particular Unique Consulting Service Proposition (UCSP) in more detail, please CLICK HERE.