Rekindle Agile Product Development

In software development, Agile practices the approach of discovering the requirements and developing the solutions through the collaborative effort of self-organizing, cross-functional teams and their customer/end user(s).

Change is difficult, but the US government is also going agile. Are you aware that “The brain processes visual information 60,000 times faster than text?”

The Artefact has been developed as a resource to understand, evaluate, and use agile and hybrid agile approaches. This practice guide provides guidance on when, where, and how to apply agile approaches and provides practical tools for practitioners and organizations to increase agility.

SUDIPTA MALAKAR

AMAZON BEST SELLING AUTHOR

In software development, Agile practices the approach of discovering the requirements and developing the solutions through the collaborative effort of self-organizing, cross-functional teams and their customer/end user(s).

Change is difficult, but the US government is also going agile. Are you aware that “The brain processes visual information 60,000 times faster than text?”

The Artefact has been developed as a resource to understand, evaluate, and use agile and hybrid agile approaches. This  course guide provides guidance on when, where, and how to apply agile approaches and provides practical tools for practitioners and organizations to increase agility.

Agile began as an iterative, collaborative, value-driven approach to developing software.

It was originally conceived as a framework to help structure work on complex projects with dynamic, unpredictable characteristics.

But since then, it has evolved into somewhat of a philosophy or world view, with a set of well-articulated values and principles common between Agile’s many varieties.

But we have noticed that many times people are misinterpreting some concepts in Agile.

Let's discuss some of the top benefits of organizational agility.

Based on our research findings and conversations with top executives, we discovered that Agile methodologies can help spur growth and support digital transformation in an era of high customer demand and fast-emerging market trends. The report shows Agile organizations experience:

• Faster time to market (60%)

• Faster innovation (59%)

• Improved non-financial results such as customer experience and product quality (59%)

• Improved employee morale (57%).

The essence of Agile development:

• Lean – eliminate waste

• Iterative – embrace change

• Incremental delivery – promote feedback

• Value-driven – enhanced ROI, reduced risk

• Collaborative – customer involvement

• Quality-focused – potentially shippable product

• Bring a just-in-time product management perspective to IT projects.

Agile is a product development & management Methodology.

Agile development is a way of thinking about software development as expressed in the Agile Manifesto, and acts as an “umbrella” for a group of methodologies. The methodologies are based on process-centric and iterative development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. Agile development is a conceptual framework that promotes evolutionary change throughout the entire life cycle of the project and represents a new, more flexible approach to development than the traditional methods that have previously been the norm for software development.

Agile Application Lifecycle Management, also called Agile ALM, Agile Application Lifecycle Management is the integrated management platform of the entire software application lifecycle, from planning to the final release. Key components of the platform include the ability to handle change management, workflow, source code management, task management, testing and bug tracking, reporting and analytics.

Agile Development Life Cycle is the complete software development process including Agile practices such as user stories, cross-functional teams, unit testing, refactoring, continuous integration, multi-stage continuous integration, planning poker, burnup charts, burndown charts.

Let’s see what is Agile Manifesto?

Principles of Agile software development: "We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan.

That is, while there is value in the items on the right, we value the items on the left more.”.

Agile Process is

A software development methodology is based on process-centric and iterative development, where requirements and solutions evolve through collaboration between self-organizing cross-functional teams and is collectively regarded as highly efficient to productivity. Specific processes include user stories, cross functional teams, unit testing, refactoring, continuous integration, multi-stage continuous integration, planning poker, burnup charts and burndown charts.

Let’s see what are

Agile Values

· Trust: Trust among the various stakeholders (team, scrum master, product owner, project manager) plays a vital role in making Agile successful.

· Respect: Individuals have to respect and consider the opinion of all the stakeholders, even if a team member is a fresher to the team.

· Openness: Team/scrum master should be open to the management and the product owner while providing the status updates, highlighting risks (both internal and external risks).

· Courage: Team should have the courage to say NO to the management if we cannot commit to the delivery with appropriate reasons.

Scrum refers to a holistic or “rugby” approach—where teams goes the distance as a unit, passing the ball back and forth, as opposed to the traditional sequential or “relay race” approach for managing new product development.

Sprint is Scrum specific word describing iterations.

Spike is Timeboxed investigation of feasibility via a bare bones implementation, which touches on all aspects of the full implementation.

Refactoring is the practice of continuously improving the usability, maintainability, and adaptability of code without changing its behavior. Refactoring makes it much easier to add new and unanticipated functionality. Refactoring has the disadvantage that it takes extra effort and requires changing the code.

Sprint Backlog is Plan for development team to map out implementation of features for an upcoming sprint.

Sprint Planning is a meeting for Scrum Teams, Scrum Masters and Product Owners where the Product Owner describes priority features to the team. The Scrum Team gets enough of an understanding about the tasks discussed that they are able to choose which ones to move from the product backlog to the sprint backlog.

Retrospective is a Meeting held at the end of every sprint review to reflect on what went well during the sprint and what can be improved upon during the next sprint. Sprint retrospectives are valued as necessary parts of inspecting and adapting, and allow development teams to plan for future output.

Sprint Review is a meeting. In the sprint review, teams go over what stories were completed during the iteration and demonstrate those stories for stakeholders and the product owner and take feedback.

Daily Meetings that are meant to quickly and efficiently resolve obstacles that any team members may be experiencing.

Story Points are Relative scale of effort required by a team to implement a user story.

User Stories are used with Agile methodologies for specifying requirements and presented as an informal statement of the requirement (usually fitting on a 3x5 index card).

Epic is a user story which describes a large amount of customer value and needs to be broken down into many smaller user stories.

About Agile Delivery

Agile delivery is a business strategy that creates value through fast feedback and short decision cycles. The agile analysis mindset is based on the Agile Manifesto and the Principles.

Agile delivery planning takes two primary forms: iterative and adaptive.

• Iterative planning prioritizes and refines the work in short cycles designed to provide focus and increase the feedback and learning gained from stakeholders.

• Adaptive planning involves the continuous change to long-term plans. Constant planning and analysis is used to prioritize and refine the work to be done to deliver the highest value.

Agile approaches deliver value incrementally, slicing the product into small pieces, prioritizing them by business value, and delivering new items of value frequently. Incremental delivery allows for rapid feedback, learning, and adapting to change.

The Agile Mindset

Agile is best described as a mindset that guides the way work is approached. Agile is not a methodology that prescribes how to do that work.

An agile mindset drives agile business analysis practitioners' thinking and behavior. This, combined with a set of practices and techniques which enable effective delivery of just enough of the right product to the right people early and often, and the focus on maximizing value, are the goals of agile business analysis.

The goal of applying an agile mindset is to maximize the outcome (value delivered) with minimum output: "do less and do the right things, right".

What is an Agile Mindset?

The agile mindset is based on a common core of human values that include respect, courage, collaboration, continuous learning, customer focus, and value maximization. These values find their clearest expression in the Manifesto for Agile Software Development (Agile Manifesto).

The main aspects of an agile mindset include

• deliver value rapidly and consistently,

• collaborate courageously,

• iterate to learn,

• simplify to avoid waste,

• consider context and adapt to realities,

• reflect on feedback and adapt both product and process, and

• produce the highest quality products.

The Agile Mindset, Methodologies, Templates and Frameworks:

Agile is best described as a mindset because the values and subsequent principles explain ideas and attitudes with which people approach a situation, but do not prescribe exactly what they do in those situations.

Every situation is unique – there is no single “agile” approach. There are a variety of techniques, processes, and tools which can be applied in different combinations to different extents depending on the context. Agile teams are best served when they select a particular combination of techniques, processes, and tools that fit their context and help them work in agreement with their chosen mindset. This combination can be considered the team’s methodology.

There are a number of branded frameworks that fall under the broad banner of agile. These frameworks are collections of specific practices and ideas that have been proven useful in a specific context. These frameworks have some common characteristics:

• respect for people and the importance of creativity in delivering value,

• the importance of rapid delivery, feedback, and learning to ensure the product or service being produced meets real customer needs,

• collaboration and communication among the team members and the stakeholder community in order to build shared understanding, and,

• break work into small slices of business value and deliver them incrementally and iteratively.

These frameworks include Scrum, Kanban, Extreme Programming, Adaptive Software Development, Lean Software Development, SAFe, LeSS, DAD, and many others.

It is important to understand that the context in which a framework worked at one time may not be the same as the context for a different initiative. There is no "one size fits all" in the agile mindset. The key to agility is to find what works in a particular context. Many teams find it helpful to combine techniques and practices from multiple frameworks to address the challenges of their context.

Agile Extension and the Agile Manifesto

The agile software development movement was founded on a document which encapsulates a philosophy of work, the Manifesto for Agile Software Development. This manifesto presents a set of values and principles which are the the underpinning of the way of working embodied in agile software development.

The Manifesto for Agile Software Development (Agile Manifesto) was penned by a group of practitioners and methodologists who sought alternatives to the way software was developed at the time. A high percentage of software development initiatives were late, exceeded their planned budget, and didn't achieve their quality goals. The teams building software were stressed, unhappy, and dissatisfied with the working environment.

The Agile Manifesto states:

“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

- Individuals and interactions over processes and tools.

- Working software over comprehensive documentation.

- Customer collaboration over contract negotiation.

- Responding to change over following a plan.

That is, while there is value in the items on the right, we value the items on the left more.”

If we apply agile thinking to business analysis we can view these statements as guidelines for a philosophy of analysis.

These statements may be rooted in software development, but they can be related to agile business analysis in any context. Replacing “working software” with “working solution” expands our thinking and gives us guidance for an approach to analysis with an agile mindset.

1. We are uncovering better ways of delivering solutions by doing it and helping others do it.

This is the most important statement in the Agile Manifesto. It reinforces the practice based and empirical nature of the agile mindset. You learn what works by trying things out, not theorizing about what might work.

2. Individuals and interactions over processes and tools.

Business analysis is a human-centric activity. Business analysis practitioners start by understanding stakeholders’ needs which requires them to work closely with stakeholders at every step of the value chain. Solutions frequently change the way people work, and agile business analysis practitioners make people the center of the work.

3. Working solutions over comprehensive documentation.

Agile business analysis practitioners focus on producing something, showing it to stakeholders, and eliciting immediate feedback to determine if they are on track to satisfying the need. Agile business analysis practitioners engage stakeholders in conversations in order to build and maintain shared understanding.

Documentation does provide value, but only when it’s written to match its intended purpose. Agile business analysis practitioners produce documentation as they implement a change and use it to facilitate and support discussions with stakeholders.

4. Customer collaboration over contract negotiation.

Agile business analysis primarily focuses on satisfying needs. Business analysis practitioners learn to understand needs by showing increments of solutions to stakeholders and analyzing the feedback received. This ongoing collaboration with stakeholders facilitates new information about the need and constantly refines the understanding of the need until the need has been satisfied.

This ongoing collaboration with stakeholders also uncovers new needs based on customer demand, new competitors entering a market, government legislation that impacts the solution, or any other factor that may impact the solution.

5. Responding to change over following a plan.

Agile approaches do plan. In some contexts the plan is called the product roadmap. In an agile context, success is measured based on how well solutions satisfy the customer’s needs and the value they derive from the solution. The ongoing learning and feedback that is central to the agile mindset allows for business analysis practitioners to continually refine their understanding of the need and make changes to the solution to ensure the solution satisfies the need.

Principles of Agile Business Analysis

The Agile Manifesto provides a set of values that form the foundation of the agile mindset. The BABOK® Guide presents the Business Analysis Core Concept Model™ which provides a set of core concepts and common language to describe business analysis. The Agile Extension to the BABOK® Guide describes seven principles for agile business analysis.

The principles that guide agile business analysis are:

• See the Whole.

• Think as a Customer.

• Analyze to Determine What is Valuable.

• Get Real Using Examples.

• Understand What is Doable.

• Stimulate Collaboration and Continuous Improvement.

• Avoid Waste.

See the Whole:

The principle of See the Whole guides business analysis practitioners the need in the context of the big picture, focusing on the business context and why a change is necessary. Business analysis practitioners examine the context in which the need exists and how the context influences the solution.

Agile business analysis assesses how the solution delivers value when satisfying stakeholders’ needs. The value for the solution is created through gaining an understanding of the context, the solution, and the stakeholders. The ideas behind "See the Whole" are influenced by systems thinking.

Think as a Customer:

The principle of Think as a Customer guides business analysis practitioners in ensuring solutions incorporate the voice of the customer through a clear understanding of the expected user experience.

A customer can be any stakeholder that interacts with the solution. Business analysis practitioners generally start with a high-level view of customer needs and progressively decompose these viewpoints into an increasingly detailed understanding of the needs the solution must satisfy. Agile approaches incorporate feedback loops to continuously validate this learning. As solution delivery progresses, both the customer’s and the organization's understanding of the needs evolve. Feedback and learning is central to ensuring these changes are incorporated into future iterations of the solution.

Analyze to Determine What is Valuable:

The principle of Analyze to Determine What is Valuable guides business analysis practitioners to continuously assess and prioritize work to be done in order to maximize the value being delivered at any point in time.

Determining what is valuable involves understanding the purpose of requirements and ensuring solution options and solution components continue to support the desired outcome. This includes avoiding waste by maximizing the amount of work not done and delivering valuable solutions early and continuously.

Get Real Using Examples:

The principle of Get Real Using Examples guides business analysis practitioners in building a shared understanding of the need and how the solution will satisfy that need.

These examples can be used to iteratively develop and elaborate analysis models to explore multiple dimensions (for example, user role, user actions, data, and business rules) of a need. This practice continuously engages stakeholders and supports a shared understanding of needs.

The level of abstraction of examples and models varies depending on the audience and the outcome being sought. For example, when planning the product, examples or models can be used to set context and identify scope. These models are more abstract and provide a broad perspective of the need. When delivering the product, the examples or models can be progressively elaborated to identify specific details of the need and the solution.

Examples can also be used to derive acceptance criteria, help design the solution, and provide a foundation for testing the solution.

Understand What is Doable:

The principle of Understand What is Doable guides business analysis practitioners to understand how to deliver a solution within given constraints. Constraints can include the capabilities of the technology used to deliver the solution, the skills of the team, and the time in which you have to deliver a valuable solution.

Understanding what is doable involves continually analyzing the need and the solutions that can satisfy that need within the known constraints. It also involves considering measures such as team capacity and velocity trends to maintain reasonable expectations on an ongoing basis.

Stimulate Collaboration and Continuous Improvement:

The principle of Stimulate Collaboration and Continuous Improvement guides business analysis practitioners in creating and contributing to an environment where all stakeholders contribute value on an ongoing basis.

Agile approaches emphasize the usefulness of continual collaboration between those with a need and those who are delivering a solution to meet that need.

A key aspect of the agile mindset is continuous improvement. Business analysis practitioners seek to continually improve the solution as well as the processes used to deliver the solution. Continuous structured and unstructured feedback allows business analysis practitioners to adapt the solution and its processes in order to increase the value being delivered.

Retrospectives are also used to examine processes and solutions, and identify opportunities for improvement. Healthy, collaborative teams have the trust and safety necessary to transparently identify opportunities for improvement and implement them.

Avoid Waste:

The principle of Avoid Waste guides business analysis practitioners in identifying which activities add value and which activities do not add value. Agile business analysis seeks to understand the need and to deliver a solution that satisfies that need. Any activity that does not contribute directly to this goal is waste.

Waste can be divided into two sets of activities:

• those that have value but do not directly contribute to satisfying the need, and

• those activities that do not add value at all.

The aim is to completely remove those activities that do not add value, and minimize those activities that do not directly contribute to satisfying the need. When avoiding waste, agile business analysis practitioners.

• avoid producing documentation before it is needed, and when documentation is needed do just enough,

• ensure commitments are met and there are no incomplete work items that adversely impact downstream activities,

• avoid rework by making commitments at the last responsible moment,

• try to elicit, analyze, specify, and validate requirements with the same models,

• make analysis models as simple as possible to meet their intended purpose,

• ensure clear and effective communication, and

• pay continuous attention to technical excellence and accuracy. Quality defects(such as unclear requirements) result in rework and are waste.

Analysis at Multiple Horizons

A planning horizon represents a view of work within an organization with of granularity appropriate to the planning time frame and the nature of the level feedback loops. The Agile Extension defines three horizons: Strategy, Initiative, and Delivery. This framework provides a model to describe agile business analysis. Individual practitioners and organizations may employ different terms, levels of granularity, and time frames based on the context of the organization and the work being done.

In constant and rapidly changing environments, organizations are required to be able to sense and respond to local opportunities and problems without the need to involve the whole organization, while also looking forward at emerging threats and opportunities. These planning horizons provide a framework for the shift in focus that occurs when moving between understanding the long-term strategic needs of the organization and the immediate needs of a customer.

Depending on the size of the organization, multiple business analysis practitioners may be independently focusing on individual horizons and continuously communicating with each other, or a single business analysis practitioner may focus on more than one horizon. Constant communication and collaboration across all horizons is learning which supports effective decision making to allow for rapid feedback and effective decision making across the organization.

Overview of the Three Horizons

The Strategy Horizon

The Strategy Horizon refers to the decisions that impact the entire organization. Business analysis practitioners operating at this horizon support decisions about strategy and the allocation of available resources in support of that strategy. Decisions made at the Strategy Horizon identify the products, services, and initiatives to which the organization allocates resources. Business analysis practitioners working at the Strategy Horizon identify short-term goals, initiatives, and risks that align to organizational strategy, and articulate the problems that must be understood in order to make strategic decisions. The time horizon of the Strategy Horizon may be as short as three months to as long as multiple years ahead. This time frame continually shifts and moves forward, creating what can be considered a rolling time frame.

The Initiative Horizon

The Initiative Horizon refers to decisions that impact a particular goal, initiative, or team. Business analysis practitioners operating at this horizon support initiative based decisions about how to create value with the resources available, as well as better understanding the needs of the stakeholders and the options available. At the Initiative Horizon, business analysis practitioners support decisions that are acted on in a shorter time period than at the Strategy Horizon and over a longer period of time than at Delivery horizon.. Feedback and learning at the Initiative horizon supports the  analysis being done at both the Strategy Horizon and the Delivery Horizon.

Agile business analysis at the Initiative Horizon may support decision makers in a single team or in multiple teams. Each team may work independently or they may be highly interdependent, leading to a need to understand complex dependencies between teams.

The Delivery Horizon

The Delivery Horizon refers to decisions made regarding the delivery of the solution. Business analysis practitioners operating at this horizon work with the delivery team to understand how to best break down work, how to deliver and test the value the team is creating, and how to learn quickly from the work the team is doing.

The team working at the Delivery Horizon works on prioritized work from the backlog and turns it into a valuable product or service that meets the identified outcome or goal of the solution.

At the Delivery Horizon, business analysis practitioners support decisions that are acted on in a shorter time period than at the Initiative Horizon and impact the solution currently being developed. Business analysis practitioners work with a variety of stakeholders including decision makers and customers to deliver value directly to the customer.

Predictive, Iterative, and Adaptive Planning

There are many ways in which business analysis practitioners plan. At the highest level, there are three most iterative, and adaptive commonly used approaches to planning: predictive, iterative, and adaptive.

Predictive Planning

Predictive planning involves performing detailed analysis and planning and then acting on that planning. An economic driver for predictive planning is the “cost of change” curve. It suggests that the later a mistake is found, the more it will cost tofix it. This in turn suggests that it is cheaper to spend more time analyzing information early on, so as to provide the fewest possible misunderstandings, gaps, and defects as possible before more work is done.

Predictive planning attempts to predict scope and risk at the beginning of a project. The planning horizon of predictive planning is the duration of the project, and project managers will therefore construct a detailed plan for the entire duration of the project. Deviations from the plan are seen as risks and a considerable body of practice exists for getting a deviant project "back on track". Feedback and learning can be suppressed in favour of maintaining the original plan.

A well prepared planner may identify potential risks and develop contingency plans based on good analysis. The challenge is that the cost of change can be a potential issue or opportunity means changing a substantial amount of detail igh as well. An unforeseen event can disrupt the plan, or worse, an opportunity cannot be accommodated because the work involved in changing the plan makes it impractical.

Iterative Planning

Iterative planning is an approach that is frequently used when long-term planning is rendered ineffective by rapid change and great uncertainty: the next step in the plan is based on the latest learning.

This suggests that each hypothesis should be tested before planning what to do next, since the hypothesis might be right, wrong, or partially right. In this situation, stakeholders and subject matter experts are learning what they need at the same time as planning is occurring. This suggests that plans are only viable for the immediate future, potentially the next one to four weeks. Business analysis practitioners identify opportunities and threats as they emerge through the constant testing of assumptions. They are able to react to potential risks because the plans are resilient and constantly evolving. In a rapidly changing, large, or complex context, not all information is immediately apparent or fully understood. Business analysis practitioners might find they have insufficient time to analyze an idea that impacts many parts of the solution, or they may find that they are doing a lot of rework as they discover new information or needs.

Adaptive Planning

Adaptive planning requires both long-term and short-term planning. Long-term plans are subject to change though and are easy to change. Short-term plans take into account and inform the long-term plans of the organization.

This comes at a cost. It means that the organization is constantly both planning and analyzing. This creates confusion, mistakes, and wasted effort if there is a lack of transparency, trust, and collaboration. Adaptive planning creates a context that supports an agile mindset and the adoption of agile approaches to business analysis.

Adaptive planning is central to agile business analysis. Organizations produce both long-term and short-term plans, but it is not planning in a linear way. Adaptive planning (sometimes referred to as rolling wave planning) treats each plan as a hypothesis to be proven. Feedback and lessons learned are used to adjust the plan in real time. Newly discovered information may change the hypotheses on which the plan is based and cause a change in the plan. If not, business analysis practitioners continue to uncover better ways to achieve the plan as they execute it.

Adaptive planning is an effective approach when there is value in fast feedback and learning, and also in long-term planning. Higher level planning horizons (strategy and initiative), are longer and information more abstract than the lower planning horizons (initiative and delivery). Resistance to change is lessened because there is less detail to change.

Agile Extension Techniques used in Strategy Horizon:

• Minimal Viable Product: used to prioritize the allocation of resources and to increase the speed of organizational learning.

• Planning Workshop: used to plan the allocation or resources across multiple initiatives and to provide a shared understanding of the purpose of a new initiative.

• Portfolio Kanban: used to provide real time visibility of the progress of initiatives across the portfolio. May also be used in conjunction with Balanced Scorecards, Value Stream Maps and other approaches to optimize the allocation of resources across initiatives.

• Product Roadmap: used to communicate the expected future direction of the product and to improve collaboration among teams in different initiatives. Also used to support decision making and prioritization.

• Purpose Alignment Model: used to prioritize potential initiatives, understand the optimum resourcing mix on initiatives and to understand the overall focus of initiatives across the organization.

• Real Options: used to understand the appropriate time for making decisions.

• Relative Estimating: used to quickly understand the relative value and resource requirements of potential initiatives across the portfolio.

• Value Stream Mapping: used to understand the creation of value across the whole customer experience to prioritize, plan and integrate the creation of value and reduction of waste between initiatives across the portfolio.

• Visioning: used to understand decision options and clarify the organization's vision. Also used to identify the purpose and focus for a new initiative.

• Backlog Management: used to track initiatives across the portfolio of work and also to understand critical risks, integration needs, and dependencies between initiatives.

• Balanced Scorecard: used to track value and measure progress across initiatives through continuous reporting and feedback across the core focus areas in the organization.

• Benchmarking and Market Analysis: used to provide input into decisions made in real time and to provide useful information to teams across the organization to support decision making and collaboration.

• Business Capability Analysis: used to support decision making and to provide input to teams making decisions that impact multiple initiatives.

• Business Cases: used to consider alternative approaches to solving strategic problems and to launch new initiatives.

• Business Model Canvas: used to consider multiple options when launching initiatives and to help scope the work of a new initiative. Also used to look at how value is created, captured, and delivered to stakeholders across the organization to allow decisions to made quickly at a strategic level, and to understand the impact of changes to both the organization and its environment.

• Metrics and Key Performance Indicators (KPIs): used to communicate priorities and measure delivery across the organization. Also used to communicate what the organization defines as necessary to create value.

• Organizational Modelling: used to prioritize initiatives and understand the available resources that can be used in initiatives. Also used to ensure that business value is created across the organization rather than seeing individual initiatives create products and services that cannot be delivered effectively by the wider organization.

• Risk Analysis and Management: used to inform decisions in real time. Also used to prioritize new initiatives and to understand the need for changing priorities

initiative based on changing circumstances beyond the horizon of a single .

• Stakeholder List, Map, or Personas: used to identify the people who need to be involved in decisions.

• SWOT Analysis: used to understand the context in which decisions will be made and to prioritize new initiatives.

• Vendor Assessment: used to understand the capabilities possessed by potential partners and vendors. Also used to understand the capabilities and available resources that vendors can provide to initiatives across the portfolio of work.

Agile Extension Techniques used in Initiative Horizon:

• Kano Analysis: used to determine the features most relevant to satisfying the identified need and determine the best approach for delivering those features.

• Personas: used to create a shared understanding of who the customer is; frequently a core item when Thinking as a Customer.

• Planning Workshop: used to create a shared understanding of the approach to constructing the solution.

• Purpose Alignment Model: used to determine the features most relevant to satisfying the identified need and determine the best approach for delivering those features.

• Real Options: used to understand the appropriate time for making decisions.

• Relative Estimation: used to make decisions about which features to deliver and in what order.

• Retrospectives: used to provide teams a means of explicitly discussing opportunities for continuous improvement.

• Story Decomposition: used to support decisions about which features to deliver, in what order, and how much of the feature needs to be delivered in order to reach the desired outcome.

• Story Mapping: used to elicit and model information about a solution, including notable features or characteristics of that solution.

• Value Stream Mapping: used to identify the portions of a problem or solution and identify what their ability is to alter the value of the affected item or process.

• Backlog Management: used almost consistently in most agile approaches.

• Balanced Scorecard: may provide measures of desired outcomes for the initiative. May be used for “scoring” different solution options or solution components for prioritization.

• Brainstorming: used to create many options for a given problem; brainstorming is a technique well suited to agile.

• Collaborative Games: used to identify potential solution options.

• Concept Modelling: used to build a shared understanding of the need and potential solutions.

• Data Dictionary: used to build a shared understanding of the relevant data in the problem and solution space.

• Data Modelling: used to elicit information necessary for making the decisions identified in the Initiative Horizon.

• Document Analysis: used to elicit information necessary for making the decisions identified in the Initiative Horizon.

• Functional Decomposition: used to build and maintain a shared understanding of the desired solution.

• Glossary: used to build a shared understanding of the problem and solution space.

• Interface Analysis: used to elicit information necessary for making the decisions identified in the Initiative Horizon.

• Interviews: used to elicit information necessary for making the decisions identified in the Initiative Horizon.

• Metrics and Key Performance Indicators (KPIs): used to provide measures of desired outcomes for the solution.

• Observation: used to elicit information necessary for making the decisions identified in the Initiative Horizon.

• Prioritization: used to determine which features will and will not be delivered as part of the initiative and in what order.

• Process Modelling: used to build and maintain a shared understanding of the desired solution.

• Prototyping: used to create a working or non-working model of a possible solution. Often helps Getting Real with Examples.

• Risk Analysis and Management: used to identify information necessary for making Initiative Horizon decisions, especially which features to deliver and in what order.

• Scope Modelling: used to build and maintain a shared understanding of the boundaries of the desired solution.

• Stakeholder List, Map, or Personas: used to build and maintain a shared understanding of the entities involved with or affected by the solution and its implementation.

• Vendor Assessment: used to provide input into decisions about which solution will satisfy the identified need.

Agile Extension Techniques used in Delivery Horizon:

• Personas: used to create a shared understanding of who the customer is, frequently a core item when Thinking as a Customer.

• Real Options: used to understand the appropriate time for making decisions, and the value that each option represents.

• Relative Estimation: used to make decisions about which features to deliver and in what order.

• Retrospectives: used as a means of explicitly discussing opportunities for continuous improvement.

• Story Decomposition: used to decompose epics to stories, which represent incremental work one on solution components.

• Story Mapping: used to elicit and model information about a solution, including notable features r characteristics of that solution.

• Value Stream Mapping: used to identify the portions of a problem or solution and identify what their ability is to alter the value of the affected item or process.

• Backlog Management: used consistently at the Delivery Horizon; backlog management is a frequent if not constant activity.

• Balanced Scorecard: used to provide structure to the learning process at this horizon.

• Brainstorming: used to create many options for a given problem, brainstorming is a technique well suited to agile.

• Collaborative Games: used to help with team building and inspire collaboration with the working group.

• Concept Modelling: used to build a shared understanding of the need and potential solutions.

• Data Modelling: used to build a shared understanding of the relevant data in the problem and solution space, and as elements of the solution are constructed.

• Functional Decomposition: used during the Delivery Horizon in the context of decomposing epics into stories, although the focus is on producing stories which have business value upon completion.

• Glossary: used to maintain any terms or definitions that the team may develop or require over time.

• Interface Analysis: used to describe a particular user or role using a feature, or how components of the solution will communicate with each other or to outside systems.

• Interviews: used to elicit information necessary for making the decisions identified in the Delivery Horizon.

• Metrics and Key Performance Indicators (KPIs): used to trace stories to metrics and the KPIs they are expected to affect.

• Observation: used to understand how users perform a task or use the solution.

• Prioritization: used to determine which features will and will not be delivered as part of the initiative and in what order. Revisited during the Delivery Horizon periodically or at an emergent need.

• Process Modelling: used to represent processes and work that is being done to create or alter those processes.

• Prototyping: used to create a working or non-working model of a possible solution.

• Risk Analysis and Management: used to make decisions, especially which stories will affect which risks, and in what way.

• Scope Modelling: used to build and maintain a shared understanding of the boundaries of the desired solution.

• Stakeholder List, Map, or Personas: used to build and maintain a shared understanding of the entities involved with or affected by the solution and its implementation. Personas here can refer to stakeholders around the solution rather than roles, which are more commonly referred to in stories used in solution construction.

Backlog Refinement

Purpose:

Backlog Refinement is used to ensure there is enough detail and clarity for items in the backlog so that the delivery team can complete an iteration.

Description:

Backlog Refinement is a continuous technique used to prepare product backlog items for an agile team to deliver. This is frequently done in preparation for a Planning Workshop. Backlog Refinement incorporates ongoing feedback and learning to revise and refine requirements of needs on an ongoing basis. Refining the backlog based on stakeholder feedback is a critical differentiator for agile initiatives. Backlog Refinement assists the delivery team in delivering a high value, high quality solution within an iteration.

Business analysis practitioners collaborate with team members, stakeholders, and customers to clarify the need and moving or removing items as reviewing priorities with stakeholders and identify additional detail.

Refinement activities vary based on what is needed to prepare the item for the delivery team. Activities may include Story Elaboration, Story Decomposition, Prioritization, and sequencing. Backlog Refinement clarifies which items are high priority for the team to deliver and re-prioritizes or removes unnecessary items. Backlog Refinement splits large items into smaller ones that meet the INVEST criteria . Acceptance criteria or additional documentation needed to deliver an item can also be added.

Refinement for an item is complete when there is sufficient information for the team to execute.

The outcome of refinement is a common understanding among the team of what is required to deliver the product backlog item (PBI). It also gives the team a chance to look ahead at what is expected next for the solution.

A commonly used construct for ensuring quality in user stories is the INVEST criteria, which calls for user stories to be:

• (I) Independent: : represents a feature which can be delivered independent of other features.

• Example: "ATM PIN entry" is independent from 'Withdrawal Amount'

• (N) Negotiable: : the team can negotiate how to deliver.

• (V) Valuable: : expresses the value to the customer.

• Example: "ATM PIN entry" allows only the correct person to access the account.

• (E) Estimable: : team can estimate effort to deliver based on past experience.

• (S) Sized Appropriately: : for the team to complete in one iteration. In general, the smaller the better.

• (T) Testable: : can be validated objectively by a stakeholder.

Not all backlog items are to be written as user stories. However, User Stories is a common technique used as they emphasize the customer value.

Elements:

1. Backlog

An ordered list of features, requirements, or items needed to achieve the outcomes for the solution. Refinement refers to the activities to keep the backlog relevant and timely for the team.

2. Backlog Item

An item on the backlog which represents one or more requirements. Items higher on the backlog are appropriately sized and include enough detail for the team to complete in the next iteration. Items lower on the backlog can be larger and less defined.

Items are most commonly presented as a user story, but can be presented in other formats such as job stories.

3. Refinement Meeting

The purpose of this meeting is for the team to review items that are at the top of the backlog. The outcome of this meeting is confirmation that the top items are ready for the next iteration and identify any further clarity needed. There is no standard format for this meeting, but it is most often led by the product owner or customer representative.

The output of the refinement meeting is backlog items ready for the next iteration.

4. Definition of Ready

This is a set of criteria the team agrees must be satisfied to consider an item "ready" for the next iteration. Initially, teams can set the criteria as a critical mass of team members agree the item is ready for the team. As the team reflects and looks to continuously improve, the team may identify additional criteria for their initiative.

Usage Considerations:

1. Strengths

• Increases clarity and common understanding of a product backlog item (PBI).

• Facilitates more effective iteration planning by raising queries early.

• Gives the product owner or customer representative time to answer queries before the team begins executing.

• Ensures product backlog items (PBIs) are sized appropriately for the team.

2. Limitations

• Can be inefficient when not aligned to the cadence of the team. If the team reviews the backlog daily as in a flow approach, then refinement should happen whenever a new backlog item is added. If the team reviews the backlog incrementally, then refinement should happen several days before a planning meeting.

• Is usually done by a few members of the team and can inadvertently preclude the views of team members not directly involved in the activity.

• Can be ineffective if the vision and roadmap change frequently.

Behaviour Driven Development

Purpose:

Behaviour Driven Development (BDD) is used to increase value, decrease waste, and increase communication between stakeholders and delivery teams by focusing on the intended customer behaviour for the solution to satisfy customer needs.

Description:

Agile values customer collaboration and working solutions to achieve desired output. Agile business analysis practitioners prioritize identifying solutions (BDD) supports that goal value in increments. Behaviour Driven Development which deliver customer through the use of real examples.

Behaviour Driven Development uses a customer readable, domain specific language to specify the intended customer behaviour which satisfies the customer need. It increases speed of delivery by developing only what is needed and creates opportunity for user acceptance test automation. BDD is a technique used to make needs clear and is designed to improve communication and understanding across all stakeholders. Examples are used to understand what the solution needs to do (development) and how to ensure that it does what is needed (testing). The product owner provides the examples and clarifies his or her thinking by doing so. Agile business analysis practitioners identify scenarios by asking “what if” questions in order to expose additional scenarios and express these as additional examples.

Discussions about solution needs are centered on concrete examples that are easily understandable by stakeholders. This leads to a more stable set of requirements than using abstract models alone. The simple format used in BDD leads to direct collaboration between all stakeholders. Collaborative sessions between the product owner, tester, and developer are frequently used. These sessions are known as “Three Amigos” sessions. Close collaboration encourages the delivery team to think like the customer and deliver only what is necessary to achieve this intended behaviour.

The terms Behaviour Driven Development, Acceptance Test Driven Development, and Specification by Example are commonly used interchangeably.

Elements

1. Examples:

Examples are expressions of real life business scenarios provided by stakeholders. Examples may also be known as scenarios and can be expressed in a number of ways including models. Business analysis practitioners facilitate the discovery of the information which is expressed in the examples and ensure that the set of examples is comprehensive.

Examples are used to discover information about the customer, and not all examples identified will necessarily be within the scope of a development effort.

2. Gherkin Syntax:

Behaviour Driven Development uses a simple grammar format, referred to as Gherkin, that allows real scenarios to be filled into the syntax. This takes the form:

GIVEN <a situation>

WHEN <an event>

THEN <expected result>

Both GIVEN statements and multiple THEN outcomes for a single scenario could be compound conditions linked with AND statements. There is only one WHEN event that triggers the scenario.

An example for an ATM:

Scenario 1: Account has sufficient funds.

• GIVEN: I'm in credit

• AND: the ATM has sufficient cash available

• WHEN: I request $20

• THEN: I receive $20

• AND: my account balance is reduced by $20

Scenario 2: Account has insufficient funds.

• GIVEN: I'm in overdraw

• AND: the ATM has sufficient cash available

• WHEN: I request $20

• THEN: I receive no money

Scenarios written in a Behaviour Driven Development format specify events, conditions, and actions are verifiable. They can serve as acceptance criteria for stories and serve as tests in support of Acceptance Test Driven Development that drive a common understanding of requirements and future solution needs.

3. Testing

There are several software products that will take examples in this format (but may have their own specific syntax and structure) and allow them to be easily converted into automated tests, thus enabling more agile delivery. Automation of examples enhances and speeds up agile analysis verification and validation activities.

Usage Considerations:

1. Advantages:

• Behaviour Driven Development (BDD) expresses customer needs in natural language, in a format that all team members can easily understand. The language is based on concrete examples rather than abstract concepts.

• The “Given-When-Then” pattern maps directly onto the “Setup-Execute-Assert" pattern that agile developers use in Test Driven Development. This means the developers can implement the tests directly rather than interpret them.

• The structure of BDD lends itself towards acceptance test automation and supports the production of effective test cases.

• Tools exist to support the use of BDD in projects, and traditional metrics such as test case coverage or requirements. These provide

• The automated examples provide the long-term documentation of the system and can be used to demonstrate traceability of requirements for internal stakeholders and external stakeholders such as regulators.

• Scenarios can be easily prioritized which supports the iterative, incremental nature of agile projects.

• Allows flexibility of documentation by creating a lightweight, living requirements and testing document.

• Can be used as acceptance criteria for a user story.

• The Gherkin Syntax can be used to facilitate and structure design discussions to keep the design team focused on a particular behaviour of the system. This is especially the case when the technique is used backwards on a high level design.

2. Disadvantages:

• It is possible to miss important scenarios unless there is someone who actively asks the “what if” and “what about” questions.

• Where business rules are very complex there could be too many scenarios to easily manage and track without tool support.

• Those maintaining scenarios and test cases must keep them current, relevant, and easy to read to effectively serve their purpose.

Impact Mapping

Purpose:

Impact Mapping is used to align stakeholders with organizational goals and the creation of customer value.

Description:

Impact maps align initiatives and delivery activities with overall organizational goals. Impact maps help all stakeholders stay focused on value creation (instead of feature development (the what). Impact Mapping enhances the the why) feedback loops between the Strategy, Initiative, and Delivery Horizons by tying activities to organizational goals.

Impact Mapping is a lightweight approach which shows a big picture view while identifying specific details. In order to ensure the discovery of information from all perspectives.

Elements:

1. Components:

There are four primary components to an impact map:

• Goal: identifies the organizational goals, the solution aims to achieve. It answers the question “why are we doing this?”

• Actor: identifies the stakeholders who can contribute to achieving the goals. It answers the question “who can influence goals?”

• Impact: identifies the actions actors can take to achieve goals. It answers the question “how will actors influence goals?”

• Deliverable: identifies which deliverables and functions will help actors achieve the organizational goals. It answers the question “what activities help actors complete goals?”

2. Process to Create:

Creating an impact map is best done as a face-to-face facilitated exercise to capitalize on the interaction between people of various expertise and knowledge areas. The steps to create an impact map include:

1. Gather all key stakeholders and team members in one space to collaborate.

2. Have space to create the visual impact map.

3. Facilitate the identification of each component, starting with goals, then actors, then impact, and then deliverables.

4. Once the impact map is created, keep it visible for later revision and refinement.

Usage Considerations:

1. Strengths:

• Gets the team focused on organizational goals rather than features.

• Reduces waste by preventing scope creep and over-engineered or overdesigned solutions.

• Provides transparency to know when business outcomes are achieved and when to stop projects before too much money is spent.

• Impact maps can be created in a short period of time.

• Gives large context with little information.

• The goals or "why" components specify quantifiable objects.

• The visual formats enhance refinement and decision making as new information is found.

2. Limitations:

• Best done through face-to-face facilitation.

• Impact maps need to be visual, accessible, and can be revised.

Estimation Types:

Different types of estimates reflect the range of accuracy expected from the estimate. Three types of project estimates* are:

- Order of magnitude: obtained in the initiation phase of a project  for the whole project with a range of –25 to +75%.

- Budget estimate:  an estimate derived during the planning phase for the whole project with a range of –10% to +25%

- Definitive estimate: an estimate derived at the start of each project stage for that stage with a range of –5% to +10% Effective software project estimation is one of the most challenging and important activities in software development.

Why do we need to Estimate?

- Be more competitive in the marketplace.

- Has a direct impact to the business.

- Direct impact to contract profitability.

- Build trust by delivering what we said, at the stated cost, within the stated timeframe.

- Improve team morale and productivity by working with realistic estimates.

- Set realistic expectations.

- Improve confidence with the clients (existing as well as prospective).

- Reduce troubled projects.

Estimation Strategies:

Understand your client requirements, business objectives.

Understand your Competition space.

Understand Industry Perspective.

Strive for re-usability, as appropriate.

Involve the right SMEs / Experts.

Estimating is not just for Project Managers - the work of Architects, Consultants and business analysts has a huge influence on the estimate.

Wherever possible, split the estimates to manageable sub-projects.

Evaluate alternate approach / methods.

Identify clear strategies to document the basis of estimates (BOE).

Estimation Approaches:

Summary of approaches that is widely used across organizations as well recognized by the Industry

- Estimating by Analogy.

- Deadline driven approach.

- Parametric approach.

- Estimating using Artifacts.

- Plan driven (Bottoms-up) estimating.

- Plan driven estimation tools.

- Parametric size driven tools (SLIM).

Approach - Analogy:

Use this approach in conjunction with another approach.

This is widely used in a response to an Indicative price or Rough Order of Magnitude (ROM) and not for basis of contract.

Requires historical data from a similar nature / scope / size / complexity and solution.

Approach – Deadline driven:

It should be considered only if you have essential deadlines which must be achieved.

It must be validated by other approaches and

is best used to indicate that a project cannot be done in the timescale, or that scope reduction is required.

Parametric Approach:

Use this approach

- when you want an indicative (ballpark) estimate for budgetary purposes, or

- need to validate estimates from other approaches.

Need to know project size, expressed in terms of the parameter/s.

Plan driven : Bottom-up Estimating:

Recommended approach, it is likely to be the most accurate estimate.

If you have a work breakdown structure available, you should use this approach.

Count up the work required from a Product Breakdown Structure, Work Breakdown Structure or Task schedule.

Estimating using Artifacts and Work distribution:

Choose project artifact/s for which you can estimate complexity and productivity, and count them up. 

Use the effort profile across project phases to estimate the effort for the non-Code & Unit Test phases.

Use this

- For indicative only.

- validation of another approach.

- If you know the artifact complexity, productivity and project effort profile.

Estimation Techniques:

Techniques refer to the specific mechanism for undertaking an estimating activity or task. Commonly used techniques

- Use case based estimation technique,

- Function point estimation technique,

- Agile Estimation technique,

- SLIM Estimation. 

Use Case based Estimation:

Widely used during solutioning stage, especially for development projects.

Use case need to be developed / documented and agreed with the client. This should map to business / functional requirement(s) -

Most organization has a standard Use-Case estimation and Resource Allocation worksheet (an excel based tool) that will generate the estimates.

Use-case practices vary considerably as to the number and content of use cases. 

Identifying the level of granularity of the use cases at the point when the estimate is made , this will substantially improve the quality of your estimate and effort allocation.

Identify the use case complexity , for example

Very  Low  - Read-only requirement, No business rules, Only one business object is involved.

Low- Maximum of one business rule with no interdependencies.

Tool provides a Low/High and nominal estimates based on the PERT algorithm.

Function Point Estimation:

Function Points are an index of the size of the application.

Based on the logical business view of the application functionality.

Independent of the physical design and build of the application.

One of several metrics required to provide a useful quantitative view of the development or support process.

Should use with a help of SME only as an incorrect FP count can lead to critical errors.

Based on the scope / project type engage FP CoC and the FP count estimate should be developed by a certified FP consultant.

IFPUG rules – steps in counting the Function Points.

Determine the boundary of the application or project that you are to count.

Take a logical view of the Transactions and Data.

Count the number of Logical Transaction and Data Entity elements.

Assign a Complexity to each element using the IFPUG rules.

Assign an FP count to each element using the IFPUG rules.

Sum the FP counts of all elements to obtain an application or project count.

Understand the Industry benchmark productivity figures and Most organization's internal productivity data for development & maintenance.

The productivity numbers are absolutely critical especially when the delivery is across multiple CIC or a distributed team.

Function Points are not universally useful.

Widely used in

- Any New Development project where an application provides new User Functionality.

- Any Package Development where the project adds to or changes the underling package functionality.

- Any Enhancement of an application where user functionality is Added, Changed or Deleted.

- Support Portfolio.

Not used in

- Infrastructure projects which provide no additional user functionality.

- Package configuration only projects.

- Corrective work  where no new functionality is being added.

Relative Estimation:

Purpose:

Relative Estimation is used to make future predictions based on past experience, knowledge, complexity, size, and uncertainty required to complete backlog items.

Description:

In an agile context, estimating is progressive and occurs in alignment with iterations. Initial estimates are not expected to be as accurate as latter estimates provided closer to delivery. The ability to accurately estimate improves over time as new information is discovered about both capacity and capabilities. The continuous feedback and learning that is central to agile business analysis provides clarity and understanding regarding the components, characteristics, and complexity of the work.

Estimates are not part of the solution and are used to guide internal decision making. Estimates provide value to stakeholders by

• determining cost and effort,

• establishing the priorities of the initiative, and

• committing to a schedule.

In addition to the basic approach of estimating based on historical knowledge, agile business analysis practitioners frequently apply a relative estimating model in which teams develop stories that define user needs and benefits. These stories are analyzed and numeric values are applied to each story as story points. Story points apply a Fibonacci scale to abstract measurement of factors indicative of story size.

A story point is a relative number assigned to each story that defines the estimated effort a team will have to apply to deliver the story. Story points are usually based on what the team knows about the story in five key areas:

• Knowledge: How much information does the team have?

• Experience: has the team done this/similar item before?

• Complexity: How difficult is the implementation likely to be?

• Size: How big is the story? How long will it take?

• Uncertainty: What variables and unknown factors might impact the story?

The total number of story points delivered within any given iteration is considered to be the team's velocity, or how much a team accomplished within the iteration. Over several iterations, teams will have a better understanding of their actual velocity. This allows them to make better informed estimates and commitments in subsequent iterations.

Elements:

There are several ways to estimate story points. Business analysis practitioners begin with

• an order of magnitude,

• a given set of resources and a fixed iteration, or

• a team based estimation of the time required for a sample of stories of different sizes, and then extrapolate from there to estimate the work that can likely be done in an iteration.

1. Planning Poker:

Planning poker is a technique to estimate story points for a team. During the Planning Workshop, the team reviews each backlog item or story. Once the team has a shared understanding of the story, each team member chooses a number based on the story point scale. Where alignment is within one degree of the team chooses one and moves on. Where there is a wide variation in numbers, the team discusses the discrepancy to uncover any assumed knowledge. The goal is for the team to reach agreement for each story point during the Planning Workshop.

2. Silent Sizing:

Silent sizing is an approach which engages the entire team in estimation activities. To do this, the team needs backlog items prepared on individual cards and a wall, table, or similar space to line up the items. Taking turns, a team member selects a card and places it along the wall. The team members repeat this for all cards, creating a linear line with the smallest cards on one end and the largest cards on the other end. The team then identifies breaking points to group similar sized items. At this point, the team assigns a number, such as the Fibonacci scale, to each grouping. Each card is assigned the size of its group.

Usage Considerations:

1. Strengths:

• A simple, reliable methodology that fits well with agile practices. It is highly adaptive and is likely to become increasingly accurate throughout successive iterations.

• The sizing approaches are highly collaborative and based on consensus, and will likely have a positive impact on development teams.

2. Limitations:

• Relative estimates are based on historical data, and accuracy is dependent upon the similarity of new stories to stories previously delivered. If new stories differ radically from previous stories, it is possible that the accuracy of the estimate may decrease.

• The accuracy of velocity is dependent on the knowledge and experience of the development team working together. Any changes to team composition will impact velocity and therefore future estimates.

• Numbers used are team specific, and comparisons between teams can lead to confusion for stakeholders.

• Relative estimates can be misconstrued as a definitive time to complete.

• Stakeholders outside the team may focus on the estimates (output) instead of value delivered (outcomes).

Agile Project Estimation:

Its all about Story points – a subjective unit of estimation used by Agile teams to estimate User Stories.

Represents the amount of effort required to implement a user story.

Ideally include both the development and testing effort to implement a story in a production-like environment.

To assess the number of story points, following techniques are commonly used –

- Estimation by Analogy – The estimate is compared to a number of other stories. Instead of comparing against a single universal baseline, the story can be estimated by comparing against an assortment of those that have already been estimated. This method is called Triangulation.

- Disaggregation - Disaggregation refers to splitting a story or feature into smaller, easier-to-estimate pieces.

- Planning Poker : It is an iterative approach to estimating size which uses the technique similar to Wideband Delphi to estimate the size of a product backlog item or a story. In estimate iteration, each team member prepares the size of the story independently. Then all the team members disclose it simultaneously and differences are discussed. The iterations of discussions and re-estimations are continued till the estimates converge for a team.

When an agile team needs to come up with the estimates for their user stories, the most common way of doing this is a collaborative game called planning poker. Planning poker is designed to provide a faster, more efficient process that has all the advantages of wideband Delphi—since planning poker is iterative, adaptive, collaborative, and anonymous enough to minimize most bias.

- Estimation with Story Points:

Story Points are relative and are an estimate of:

- the amount of effort involved.

- the complexity.

- the risk inherent in it.

Story Points allow to completely separate the estimation of effort from the estimation of duration.

There are 2 ways to estimate Size with story points:

Start with the smallest user story and assign it 1 Story Point. Estimate every other user story in relation to that.

Start with a user story of middle size, and assign the middle number on your scale to it. Proceed as above.

- T-shirt sizes :

Agile estimation can get tricky and there are multiple ways of doing it. The most widely used method is explained below, using t-shirt production as an example:

1. Development Team and Product Owner do high-level size estimation of the Product Backlog by assigning t-shirt sizes. This is done during Product Backlog Refinement.

Example: Extra Small (XS), Small (S), Medium (M), Large (L), Extra Large (XL), and so on.

2. The t-shirt sizes are then converted to story points. This is done during Product Backlog Refinement.

Example : The t-shirt size "XS" can be assigned a value of 2 story points, "S“ 3 story points, "M" 5 story points, "L" 8 story points, "XL" 13 story points, and so on. The story points are ordered in progressive increments, such as Fibonacci series (as in our example), or multiples of 2, and so on.

3. Story Points are then further refined as ideal days for sprint backlogs and ideal hours for tasks. This is done during the Sprint Planning.

Example : A backlog item of size 5 story points can take 4 days to complete, which again can be broken into individual tasks that may take anywhere between 2-8 hours to be done.

Wideband Delphi:

Wideband Delphi is a group-based estimation technique in which a panel of experts submits estimates anonymously so that none of the participants know who has made which estimate. This anonymity produces improved estimates because it minimizes the cognitive and psychological biases that can result in flawed estimates, including:

- The Bandwagon effect: People tend to converge around the view point that is gaining the most adherents, even if it doesn’t reflect their own opinion.

- HIPPO decision making (HIPPO =Highest-Paid Person’s Opinion): People gravitate to the ideas of experts or superiors, rather than judging ideas on their own merit. Nobody wants to

disagree with the boss.

- Group think: People make decisions to maintain group harmony rather than expressing their honest opinions.

The wideband Delphi estimation process starts with a planning effort to define the “problem” that is being analyzed, i.e., the work that is being estimated. Instead of estimating the whole project at once, the expert group breaks it down into more manageable chunks. They create a problem specification, identify the assumptions and constraints, and outline the process for the estimation rounds. This plan specifies details such as the measurement units that will be used (e.g., person weeks, hours, dollars, etc.), whether the estimates should include documentation time, and the exit criteria that they are aiming for (e.g., we want to get to +/- 20percent tolerance on the estimate range).

Before the experts begin creating estimates, they read the problem specification and discuss any qualification questions. They each list the tasks involved in the part of the project that is being estimated and enter their estimates for each task. After the first round of estimation, the facilitator gathers their estimate sheets and plots them on a chart, being careful not to identify which estimate is from which estimator.

Wideband Delphi estimation reflects agile values, because it is:

» Iterative: The process is repeated several times, until a consensus is reached.

» Adaptive: Team members have a chance to update and improve their next round of estimates based on discussion with other participants.

» Collaborative: A team-based collaborative process improves participants’ buy-in to the results.

Despite these agile characteristics, wideband Delphi isn’t widely used by agile teams. However, it is important to understand how and why this method works, since it is the basis for another technique that is widely used in agile, planning poker.

Planning Poker:

Planning Poker® is a consensus-based estimating technique. Agile teams around the world use Planning Poker to estimate their product backlogs. Planning Poker can be used with story points, ideal days, or any other estimating unit.

Each estimator is holding a deck of Planning Poker cards with values like 0, 1, 2, 3, 5, 8, 13, 20, 40 and 100, which is the sequence we recommend. The values represent the number of story points, ideal days, or other units in which the team estimates.

The estimators discuss the feature, asking questions of the product owner as needed. When the feature has been fully discussed, each estimator privately selects one card to represent his or her estimate. All cards are then revealed at the same time.

If all estimators selected the same value, that becomes the estimate. If not, the estimators discuss their estimates. The high and low estimators should especially share their reasons. After further discussion, each estimator reselects an estimate card, and all cards are again revealed at the same time.

The poker planning process is repeated until consensus is achieved or until the estimators decide that agile estimating and planning of a particular item needs to be deferred until additional information can be acquired.

Key Points for Agile Estimation:

Here is a summary of some key points about agile estimating.

» Why do we estimate? Estimates are necessary for scheduling the project and determining which pieces of work can be done within a release or iteration, (in the initial planning effort, high-level estimates are also needed to calculate the expected financial return and get the project approved.)

» When do we estimate? Agile teams continuously refine their estimates until the last responsible moment before the work is done. Up-front estimates are certainly necessary, but they are also the least accurate since that is when we know the least about the project. So agile teams progressively elaborate their estimates throughout the project, factoring in actual costs and velocity to date to create increasingly more accurate estimates going forward.

» Who estimates? In agile methods, the team members who will be doing the work are responsible for estimating their own work. They know the most about the technology, and their involvement gains their buy-in and commitment to the estimates.

How are estimates created? Estimates are created by progressing through the stages of sizing, estimating, and planning (as explained below). To create a holistic estimate, the development, rollout, and maintenance costs also need to be factored in.

How should estimates be stated? There is always some degree of uncertainty in our estimates. Therefore, estimates should be stated in ranges (e.g., “$4,000 to $4,500,” or “16 to 18 months”) that show their degree of certainty, to manage stakeholder expectations.

SLIM Estimation Tool:

SLIM - Software Lifecycle Management (SLIM) tool is rich in functionality and based on historical data, it can be used to prepare top-down estimates and explore alternative approaches in a time-effective manner.

SLIM is a top-down estimating tool.

Best practice is to use two or more approaches.

SLIM will only be one of these approaches.

It can be used for development, integration, and maintenance projects being highly configurable to estimate many design processes.

SLIM is grounded in historical data and applies proven algorithms to mitigate risk.

SLIM enables users to compare new estimates with industry or locally-gathered historical data to help compare and validate an estimate.

Once a SLIM estimate has been established, the tool enables users to modify estimate parameters (e.g. add time, increase staff numbers, etc.) quickly to predict the likely impact of changes to end date, cost, quality and overall effort.

SLIM can be used throughout the project lifecycle to incorporate any scope variations and the associated impact to delivery date, effort and quality (defect predictions).

How accurate is the estimate?

Whenever an estimate is generated, everyone wants to know how close the numbers are to reality. Well, the bottom line is that you won’t know exactly until you finish the project – and you will have to live with some uncertainty.

For example

- The nominal (expected) effort estimate is 4,000 person hours, with a 50% likelihood of achieving this.

- There is a 90% chance of the actual effort being between 3,600 and 5,000 person hours.

Estimating with Variance provides a means to determine the upper and lower bounds of an estimate or estimate components.

Commonly used variance techniques are

- Wide Band Delphi .

- PERT - Program Evaluation and Review Technique .

- Monte Carlo Technique .

Monte Carlo Simulation:

Monte Carlo(MC) - is a way of building up models that uses sampling to observe the behavior of systems where the passage of time plays no substantive role. It is usually a way to quantify probabilistic behavior, but not always.

Monte Carlo simulation helps us to get an accurate picture of how all of the sources of variation interact.

SLIM-Estimate uses Monte Carlo analysis to determine the probability of effort, duration and approximate cost by simulating the project thousands of times

A Monte Carlo analysis looks at thousands of simulations of a project using different combinations of these variables. Some will be very high. Some very low. As a result, a range of possibilities for each project parameter emerges, with some being more or less likely.

Let’s discuss around 70 Common Agile Product Development Myths.

Myth #1: Isn’t Agile Just for Software Development?

People think that Agile is used only for Software development.

But in reality,

this is entirely false.

ü Agile works for all kinds of Products development, (example, Toyota cars, Nikon Camera etc.), software is one amongst them.

ü Agile these days is used for all forms of product development, from physical products to cloud-based software-as-a-service (SaaS).

ü But beyond product development (both hardware and software), agile is being used successfully by:

Ø Marketing teams to plan and execute campaigns

Ø Lawyers to manage cases and workload

Ø Students planning exams

Ø Couples planning weddings

Ø Families for improving time together

Ø Human resources to manage their workload

Ø Organizational transformation efforts, in particular when transitioning to agile

Ø Senior leadership teams to manage their organizations

Ø And, of course, many more

Myth #2: Can’t stakeholders introduce change whenever they want?

People think that

Stakeholders can introduce change whenever they want.

But in reality,

it is not True always.

ü If the change is introduced at the right time, there may be little or no cost. Introduced at the wrong time, though, and there is a cost.

ü Being agile cannot eliminate all costs of stakeholders introducing change. However, good agile teams can reduce the cost of change regardless of when the change is introduced. Common ways of doing this are as follows:

• short iterations

• small product backlog items

• Finishing each product backlog item as quickly as possible, usually by minimizing the number of items being worked on concurrently.

ü None of this is to say that teams shouldn’t welcome appropriate changes. Some stakeholder-requested changes can be very important. But, the benefit of making each change needs to be assessed against the cost of changing and that cost is not always zero.

Myth #3: Doesn’t everyone need to be a generalist on an Agile team?

People think that

Everyone needs to be a generalist on an Agile team.

But in reality,

this is entirely false.

ü Agile teams don’t need everyone to have every skill. Instead, what agile teams need is to value any individuals who do possess skills in multiple disciplines. They can help each other always.(Example, dev team and testing team)

ü Having a few team members with multiple skills helps manage the balance of types of work. That is, sometimes the team needs more testing capacity.

ü But this can be accomplished on most teams even if a few team members are truly specialists and expert at only one discipline.

Myth #4: I’ve heard that Agile teams don’t (or can’t) plan.

People think that

Agile teams don’t (or can’t) plan.

But in reality,

this is entirely false.

ü Agile teams don’t have an upfront planning phase. They plan incrementally by continuous inspection and adaptation based on Customer priority / business outcome.

ü Instead, good agile teams conduct planning as a series of smaller, recurring activities that ensure their plans always reflect the realities of the current situation.

ü In this way, teams develop plans the same way they develop products: by inspecting and adapting.

ü Consider a traditional team with analysis, design, coding and testing phases. If lucky, that team may delay committing to a plan until the end of the design phase. But at that point, this team has no idea how fast they are at coding and testing—they haven’t done any of those activities yet.

ü In contrast, agile team turns the entire build into multiple iterations. Each iteration includes a little analysis, design, coding, and testing. This gives the agile team more and earlier insight into how quickly it can turn ideas into new features.

Myth #5: Don’t Agile teams create products with no architectural plan?

People think that

Agile teams create products with no architectural plan.

But in reality,

this is entirely false.

ü Agile teams don’t have an upfront phase during which all architectural decisions are made. Instead the architecture of a product emerges over time.

ü They architect and design incrementally by continuous inspection and adaptation based on Customer priority / business outcome.

ü This occurs by technical team members focusing first on any aspects of a product they consider risky. For example, if delivering a product with the needed throughput will be challenging, the team and product owner would elect to work on functionality early on that reduces that risk.

ü In this way, the emergent architecture of an agile product is also intentional. The architecture doesn’t just show up one day. It emerges gradually and guided by the intent of the technical team members.

ü This means that agile products do possess an underlying architecture. But decisions about that architecture are made as needed through the course of the project rather than being made entirely at the start of the project.

Myth #6: Isn’t SPRINT Planning just for internal team?

People think that

SPRINT Planning is just for internal team.

But in reality,

it is not true always.

ü Sprint planning happens first day of the Sprint having Time-box 8 hours for 4 weeks Sprint. Generally Product Owner, SCRUM Master and team attends it.

ü But high-level recommendation is to involve business / customer in Sprint planning so that

Ø Both shared common Sprint goal and Sprint backlog is achieved by the end of sprint planning in sync with all key stakeholders and thus we can avoid unnecessary product development silos

Ø Make sure Product owner in sync with business can decide WHAT can be delivered in the shippable product increment resulting from the upcoming sprint?

ü Make sure Team can decide HOW they will complete the work that they are committing to for this Sprint. In practical terms, the team looks at each of the Product Backlog Items (refined PBI, and usually written as User Stories) and identifies all of the tasks that need to be completed for the PBI to be considered ready for production.

Myth #7: Isn’t Daily stand-up meeting is just a status call?

People think that

Daily stand-up meeting is just a status call.

But in reality,

This is entirely false.

It is not status tracking event or it is not problem-solving event. Rather it is a problem identification event and iterative interactive team daily planning event to understand

• Where the Development Team is in terms of achieving common Sprint Goal?

• How Development Team can do differently, i.e., how Development Team can change the tactics to achieve more towards common Sprint Goal in order to produce releasable product increment?

• Development team tracks sprint roadmap progress based on Sprint Burndown / Burn up Charts where Effort Unit Story Points is plotted against Sprint number of day. Make sure everyday

ü Sprint Burndown chart updating happens, team also checks the Sprint Burndown chart to track their progress based on results delivered.

ü Outcome (Plan for next 24 hours and List of impediments (if any).) is achieved

ü Involve Product Owner (optional) in daily stand-up call along with scrum master (optional) and team (mandatory) so that FULL team can be on sync always.

Let’s discuss some Key Takeaways on Daily stand-up meeting.

Generic Challenges faced in Daily stand-up meeting are

- The team is all working on separate things, no common Sprint Goal.

- ‘Mini-waterfall’ syndrome i.e., cross dependency.

- Self-organization is a buzz word that has little practical meaning for the team.

- All Teams are not in sync in case of distributed teams.

- Mobile Friendly Cloud enabled cost optimum tool is missing for 24X7X365 customer support.

- Not validating if the product backlog is refined.

- Product Owner is dictating on HOW.

- Over committing and not keeping slack time within sprint(s).

- No capacity planning based on previous team velocity and team vacation planner.

- Too much time spending on tasks and estimation.

Daily Scrum Meeting Best Practices are

- Choose a time that works for everyone.

- Always focus on outcome rather than output.

- Always focus on achieving Sprint Goal.

- Keep stand-up efficient and keep everyone engaged, avoid making duplicate conversation and make the discussion short and crispy. Rotate who keeps time to make sure everyone is accountable and invested. If everything is fine, you may make it less than 15 minutes. Remember it’s a problem identification meeting, but it is not problem-solving meeting.

• Stand in a circle near your desks.

• Review and update sprint backlog every day.

• No side conversations.

• Meeting rules notice.

• Recommendation is to keep same time and same place every day.

• Make effective use of Daily Scrum Meeting (DSM) Tool, JIRA Tool, Stride + stand-up for distributed teams.

• DSM)APPLICATION SOLVES MANY PRACTICAL ISSUES THAT EVERY PROJECT EXPERIENCES IN THE DEVELOPMENT STAGE.

• Manage your workload, communicate with your team, and celebrate success.

Let’s discuss some Benefits of Daily Scrum Meeting.

• It improves communication within the Team.

• It identifies impediments, if any, in order to facilitate an early removal of the same, so as to minimize impact on the Sprint.

• It highlights and promote quick decision-making.

• It improves the team’s level of knowledge.

Myth #8: Isn’t SPRINT Review just for internal team to show business Demo?

People think that

SPRINT Review is just for internal team to show business Demo.

But in reality,

This is entirely false.

Always involve Business &/or Customer and key stakeholders in the Sprint review and let the Business &/or Customer and key stakeholders to drive the sprint review in order to achieve the below outcome.

ü Feedback on product

ü Updated Product backlog

ü Market direction for the product based on current market conditions

Sprint review happens last day of sprint having time-box 4 hours for 4 weeks sprint. The sprint review is about Scrum’s core principle: inspect & adapt. The development team, the product owner, and the stakeholders (including customer &/or business) need to figure out whether they are still on track delivering value to customers. It is the best moment to create or reaffirm the shared understanding among all participants whether the product backlog is still reflecting the best use of the scrum team’s resources. It is also because of this context that calling the sprint review a “sprint demo” does not match its importance for the effectiveness of the scrum team.

The sprint review is thus an excellent opportunity to talk about the general progress of the product. The sprint review’s importance is also the reason to address sprint review anti-patterns as soon as possible.

Myth #9: Isn’t SPRINT Retrospectives just for removing impediments in internal team?

People think that

SPRINT Retrospective is just for removing impediments in internal team.

But in reality,

It is not true always.

Product Backlog grooming is captured in retrospective to remove the impediments, to remove blockers between multiple vendors / external teams, to remove aging issues, to facilitate the dependencies between multiple vendors as SPRINT Retrospective is extremely important meeting and great opportunity for the team to inspect & adapt how they are working as a team. Recommendation is to involve Product Owner (optional) in Retrospective along with scrum master (optional) and team (mandatory) so that FULL team can be on sync always. After retrospectives team comes up with an action plan for some high priority improvements. The retrospective never changes in composition, venue, or length.

Retrospective happens last day of sprint having time-box 3 hours for 4 weeks sprint.

ü Never involve your line manager in the Retrospective.

ü Actively involve and engage all the team members in Retrospective

ü Have suitable Venue

ü A retrospective is a substantial investment and should be taken seriously. Taking notes and photos supports this process

ü The retrospective never changes in composition, venue, or length.

ü There are so many things a scrum master can do to make retrospectives great again and reduce the absence rate.

ü Randomly canceling the retrospective to achieve a sprint goal is a clear sign that the team does not understand basic agile principles, such as continuous improvement. If the scrum team repeatedly does not meet a sprint goal, it should inspect what is going on here.

Customer feedback Team is implementing here immediately, also discussed on different techniques of Retrospective.

People think that any Sprint always ends after Retrospective. But it is false. In reality Retrospective happens on the last day of any Sprint but after Retrospective office business hours may not end always.

Myth #10: Doesn’t Product Backlog grooming done with no business value defined or without defining any acceptance criteria?

People think that

Product Backlog grooming is done with no business value defined or without defining any acceptance criteria.

But in reality,

This is entirely false.

Product owner (accountable) shall always do Product Backlog grooming with tangible business value defined and by defining the acceptance criteria after discussion with customer and business, it can establish the shared vision among team.

Myth #11:

People think that

Think Small.

But in reality,

Think Big.

Get an end-to-end view of what's necessary in order to build the right product, for the right audience with the right design.

Some countermeasures could be Customer journey mapping, value stream mapping and End-to-end Value Stream Teams for better ownership, control and speed in solution design & delivery.

Myth #12:

People think that

Build Big.

But in reality,

Build Small.

Long, large batch delivery cycles make feedback so expensive that you ignore it, as well as limit potentials returns.

Some countermeasures could be

- Plan smaller releases using techniques like Story Mapping.

- Implement DevOps CI/CD capabilities so that releases are cheap and fast.

- Consider Cost of Delay when prioritizing to show when early release would make the biggest difference(s).

Myth #13:

People think that

Iterate without Intent.

But in reality,

Iterate with Intent.

Team needs to work on shared common Sprint Goal(s) and needs to have strong feedback loops closely linked with real audiences and real business results.

Some countermeasures could be

- shared common Sprint Goal(s) / objectives and key outcomes can link delivery goals to current organizational needs and guide experimentation.

- minimum viable products should focus on assessing the risky bits rather than the obvious ones.

- set-based design pursues multiple solution paths in parallel, while integrating often. It improves speed of learning and adaptation.

Myth #14:

People think that

Go it Alone.

But in reality,

Go it Together.

It’s the overall team(s) outcome rather than individual person’s contribution to produce successful Customer deliverables / business outcome.

Some countermeasures could be

- Gemba walks and ethnographic observation are good ways to familiarize the team with their customers, users and domain.

- innovation / ideation days can revive a weary team each quarter while alternatively targeting the most painful, wicked and interesting problems.

Myth #15:

People think that

Wander in the Weeds.

But in reality,

Wander High and Low.

Your efforts as Agile coach / Scrum Master are mostly tactical keeping your team focused, self-organized and empowered.

Some countermeasures could be

- focus on strategy where the team needs your help the most: connecting to feedback sources, managing stakeholders, protecting team from outside odds and so on.

- let your product owner & team lead tactical product & sprint backlog management while being available when they need you.

- Be transparent and share with your team the market context, the customer feedback and the results that their product delivers. Swim down to help them with details and understand their insights and needs.

Myth #16:

People think that

Product owner generally absent in Scrum Ceremonies like Sprint Planning & Sprint Review.

But in reality,

Product owner’s presence is mandatory in Scrum Ceremonies like Sprint Planning & Sprint Review.

Myth #17:

People think that

Customer and business are generally absent in Sprint Review.

But in reality,

Customer and business’s presence are mandatory in Scrum Ceremonies like Sprint Planning & Sprint Review.

Myth #18:

People think that

One person performs the role of both Scrum Master and Product Owner.

But in reality,

Product Owner and Scrum Master position can never be shared.

Myth #19:

People think that

No documentation is required in Agile Project.

But in reality,

Do bare minimum documentation. Do as much documentation as require by your context.

Myth #20:

People think that

Just start coding without design.

But in reality,

First Iteration is used for all planning, process, methods, tools and infrastructure set up. Architecture and Design are done, but evolve throughout project.

Myth #21:

People think that

Loss of control in Agile Projects.

But in reality,

Sponsor and Agile Coach have full picture of true progress and full control at start and end of each iteration.

Myth #22:

People think that

Scrum can’t be used for critical projects.

But in reality,

Scrum has been used by FDA-approved (i.e., life critical) projects.

Myth #23:

People think that

Scrum doesn’t scale.

But in reality, we can scale Scrum.

Scrum of Scrums can be used by several projects with 500+ people.

Myth #24:

People think that

Scrum is not used at big corporates.

But in reality,

Scrum is used at big corporates, for instance, in Google, Nokia, IBM, Yahoo, Microsoft, Siemens, BBC, Suncorp, Telstra.

Myth #25:

People think that

Product Owner is dictating HOW in Sprint Planning Meeting to the Development Team.

But in reality,

Product Owner can dictate only WHAT to the Development Team. The Development Team decides how many items (from the set offered by the Product Owner) to build in a Sprint, and how best to accomplish that Sprint goal.

Myth #26:

People think that

Product Owner is doing Sprint Backlog grooming

But in reality,

No, Product Owner can’t do it. Development Team can do only Sprint Backlog grooming.

Myth #27:

People think that

Development Team is doing Product Backlog grooming.

But in reality,

No, Development Team can’t do it. Product Owner can do only Product Backlog grooming.

Myth #28:

People think that

Scrum Master is doing always Release planning.

But in reality,

No, Scrum Master can’t do it. Product Owner can do only Release planning.

Myth #29:

People think that

Sprint cancellation is being done by Scrum Master always.

But in reality,

No, Scrum Master can’t do it. Product Owner can do only Sprint cancellation.

Myth #30:

People think that

You can never involve your Product Owner in Sprint Retrospective.

But in reality,

Yes, on case-to-case basis you can involve your Product Owner in Sprint Retrospective.

Myth #31:

People think that

In Scrum Team, we have Team Lead & Project Manager role.

But in reality,

It is always FALSE.

In Scrum Team, we don’t have Team Lead & Project Manager role.

Myth #32:

People think that

In Scrum Team, Team Lead & Project Manager always assign work to the Development Team.

But in reality,

It is always FALSE.

It works always on PULL rather than PUSH.

Myth #33:

People think that

Product Owner is doing Product Backlog grooming without proper daily interaction with Customer and business.

But in reality,

It is always FALSE.

Product Owner needs to do Product Backlog grooming as per Customer and business priority

Myth #34:

People think that

We are using Scrum in Simple environment where scope is frozen.

But in reality,

It is False.

We can use Waterfall here.

We can use Scrum in complex environment where customer requirement is changing.

Myth #35:

People think that

We are using scrum where team size is 13.

But in reality,

It is False.

We can use scrum where team size is 3 to 9.

Myth #36:

People think that

Scrum has 4 roles.

But in reality,

It is False.

Scrum has 3 roles.

3 Roles

o The Scrum Master

o The Product Owner

o The Development Team.

Myth #37:

People think that

Scrum has 3 Meetings.

But in reality,

It is False.

Scrum has 4 Meetings.

4 Meetings

o Sprint Planning

o Daily Scrum

o Sprint Review

o Sprint Retrospective.

Myth #38:

People think that

Scrum has 4 Artifacts.

But in reality,

It is False.

Scrum has 3 Artifacts.

3 Artifacts

o Product Backlog

o Spring Backlog

o Product Increment.

Myth #39:

People think that

Scrum has 2 Activity.

But in reality,

It is False.

Scrum has 1 Activity.

o Product Backlog Refinement.

Myth #40:

People think that

No Rules = No Accountability is required in Scrum projects.

But in reality,

It is False.

Rules or Accountability is mandatory in Scrum projects.

Myth #41:

People think that

No Accountability = No Transformation is required in Scrum projects.

But in reality,

It is False.

Accountability or transformation is mandatory in Scrum projects.

Myth #42:

People think that

Leadership activeness is missing in impediments resolution.

But in reality,

It is False.

It’s mandatory.

Team’s success is directly proportional to Leadership activeness in impediments resolution.

Myth #43:

People think that

Forecasting is not possible in Agile projects.

But in reality,

It is False.

Forecasting is possible in Agile projects. (Example, using Velocity, %Throughput Predictability etc.).

Myth #44:

People think that

Platform for Partners & Coach is missing.

But in reality,

it is False.

Help create practice fields and discover the opportunities of agility.

Myth #45:

People think that

System thinking & problem-solving skills are missing in desired Scrum Master.

But in reality,

It is False.

It’s mandatory.

Myth #46:

People think that

Empathy or Emotional Intelligence skill is missing in desired Scrum Master.

But in reality,

It is False.

It’s mandatory.

Myth #47:

People think that

Mentor or Coach or Facilitator or Negotiation and collaboration skills are missing in desired Scrum Master.

But in reality,

It is False.

It’s mandatory.

Myth #48:

People think that

Decision making skill is missing in desired Scrum Master.

But in reality,

It is False.

It’s mandatory.

Myth #49:

People think that

Empowerment or Delegation over Authority skill is missing in desired Scrum Master.

But in reality,

It is False.

It’s mandatory.

Myth #50:

People think that

Creativity and Innovation skills are missing in desired Scrum Master.

But in reality,

It is False.

It’s mandatory.

Myth #51:

People think that

Conflict resolution skill is missing in desired Scrum Master.

But in reality,

It is False.

It’s mandatory.

Myth #52:

People think that

Scrum Master does not promote Kaizen thinking or/and never involves in Waste reduction.

But in reality,

It is False.

It’s mandatory.

Myth #53:

People think that

Scrum Master does not help to maintain external radiators of team progress.

But in reality,

It is False.

It’s mandatory.

Myth #54:

People think that

Scrum Master does not facilitate Scrum events.

But in reality,

It is False.

It’s mandatory.

Myth #55:

People think that

Scrum Master does not promote the Scrum Values and Principles from Agile Manifesto.

But in reality,

It is False.

It’s mandatory.

Myth #56:

People think that

Scrum Master does not protect the Teams from interruptions.

But in reality,

It is False.

It’s mandatory.

Myth #57:

People think that

Scrum Master does not own Impediments removal.

But in reality,

It is False.

It’s mandatory.

Myth #58:

People think that

Scrum Master does not ensure the Work & Impediments are made visible to all Key Stakeholders.

But in reality,

It is False.

It’s mandatory.

Myth #59:

People think that

Scrum Master does not coach the Team & Product Owner in Scrum.

But in reality,

It is False.

It’s mandatory.

Myth #60:

People think that

Scrum Master does not encourage Creativity or unique perspectives of team member(s)

But in reality,

It is False.

It’s mandatory.

Myth #61:

People think that

Scrum Master is not transparent in communication.

But in reality,

It is False.

It’s mandatory.

Myth #62:

People think that

Scrum Master never challenges Traditional ways of working.

But in reality,

It is False.

It’s mandatory.

Myth #63:

People think that

Agile can never be used in Personal life.

But in reality,

It is False.

We can use Agile in our personal life as well. Example, in Students life, during Parents Teachers meeting.

Myth #64:

People think that

Agile team is not using any Prioritization techniques.

But in reality,

It is False.

It’s mandatory.

Formula for Successful Product Agility:

- Identify the value that impacts business and develop vision & roadmap accordingly.

- Deliver frequently & faster by vertically slicing their needs.

- Ask the right questions to build.

- Build products that customers love.

- Nurture undaunted teams.

- Engage customers / business in your daily routines.

- Build anything that results in customer delight.

- Minimize Waste to maximize Value.

- Product: Avoid over production by involving customers / business in your routines.

- Process: RCA and actionable items from Retrospectives.

- Metrics: Measure everything that results in Customer satisfaction.

Why Agile Fails:

Agile is not appropriate for…

• PROJECTS without significant urgency, complexity and novelty (uniqueness).

  
  

• TEAMS which are not self-organizing and do not believe in inspecting and adapting.

  
  

• ORGANISATIONS which do not invest in good engineering practices (e.g. TDD, CI etc.) and cross-functional teams.

  
  

• CUSTOMERS who are not willing to be part of the product development team and provide continuous feedback.

  
  

• Big Bang – across the board changes without experimentation

  
  

• Iterative development without Automated Tests

  
  

• Sprints (Iterations) that deliver incomplete work

  
  

• Doing mini-waterfalls within the Sprint (Iterations)

  
  

• Implementing Agile without believing in its core Values and Principles.

  
  

Prioritization Techniques:

The product owner, business stakeholders, and the team must have a clear understanding of the techniques to be implemented and the rationale associated with each priority.

Also, care needs to be taken to ensure that the definition of priorities does not change or get diluted over the course of the project.

There are three prioritization techniques that can be applied within Agile:

1. MoSCoW.

2. Kano Model.

3. Relative Weighting.

The term ‘Pruning the Backlog’ refers to the process of continuously prioritizing the backlog.

Prioritization Techniques — MoSCoW:

Dynamic Systems Development Method (DSDM), an Agile Methodology, recommends prioritization of requirements using the MoSCoW technique.

Under this technique, the requirements are prioritized based on the following:

• Must (M) — These requirements are mandatory.

• Should (S) — These requirements are highly desirable, though not mandatory.

• Could (C) — These requirements are nice to have.

• Won’t (W) — One should not work on these requirements at this point in time.

Prioritization Techniques — Kano Model:

Kano Model was developed by Professor Noriaki Kano. This model strives to fulfil requirements and ensure customer satisfaction.

Under this technique, the requirements are prioritized based on the following:

• Basic Needs.

• Performance Needs.

• Excitement Needs.

Kano Model — Categories:

The four categories of the Kano Model are as follows:

Threshold

(Must Have) : These features must be present in the product for it to be successful.

Linear

(Performance requirements): Here, customer satisfaction correlates linearly with the quantity of the feature.

Exciters and delighters: features provide great satisfaction, often adding a premium price to the product. Lack of these will not decrease customer satisfaction below neutral.

Indifferent: These features are least important to the customer. They will return or add no business value.

Prioritization Techniques — Relative Weighting:

Relative Weighting Technique was created by Karl Wiegers. This technique is based on the premise that the features that provide the highest benefits after adjustment for costs, risks, and penalties, should have the highest priority.

Key aspects of this techniques are:

• A feature’s priority is directly proportional to the value it provides, and inversely proportional to its cost and the technical risk associated with its implementation.

• Each category uses a scale of 1 – 9.

• Benefits reflect the value a feature will provide, while penalties reflect the negative effect a customer will experience if the feature is not included.

• Further, risks reflect the challenges of implementing the feature, and costs reflect the actual costs of implementing the feature.

Spikes:

Purpose:

Spikes are used to time-box research, design, exploration, investigation, or prototyping activities in order to understand the effort required to deliver a backlog item or an initiative.

Description:

When a backlog item or initiative that cannot be estimated is identified, business analysis practitioners use Spikes to gain the knowledge necessary to estimate what is required to deliver the backlog item or initiative.

Spikes are time-boxed activities that have clear objectives and desired outcomes. Spikes are exploratory in nature and do not produce a potentially shippable product. This includes exploring different potential approaches to a problem including researching different interfaces or tool options.

Spikes are often technical, and may be done to prototype a solution approach to the feature. This technique allows delivery teams to learn how to deliver a working product effectively and efficiently.

Elements:

1. Spike Goal:

Each spike has a defined goal or outcome in order to define when the purpose has been completed. Business analysis practitioners define a specific time-box to devote to this spike within an iteration.

2. Type of Spike:

There are three types of Spikes:

• Functional: analyzes a story and determines how to break it down into smaller stories or tasks, or identify where the risk and complexity exists.

• Technical: determines feasibility or impact of a story or task to understand the technical design necessary.

• Exploratory: explores organizational risks or impacts for a particular initiative or backlog item.

Usage Considerations:

1. Strengths:

• Specific activities and time-box provides focus for the team to get clarity.

• Gives permission to spend time on value-driven research.

• When used early in team formation, can help team members build and share knowledge about each other and the technology to be used for the solution.

2. Limitations:

• Can be too long a time-box or too large an item to have clear objectives and outcome.

• The term can be incorrectly used to reference follow-up conversations.

• If used too frequently, this indicates the product backlog refinement is not meeting team needs.

Minimal Viable Product:

Purpose:

Minimal Viable Product (MVP) is used to avoid cost and risk associated with developing the wrong product by testing a hypothesis, reducing waste, or increasing speed to customers for feedback and adoption.

Description:

Minimal Viable Product (MVP) identifies the smallest set of features or requirements to deliver value to stakeholders and satisfy early adopters in the shortest time possible. It focuses on core features sufficient to deploy and deliver stakeholder value and no more. Further features are developed after considering feedback from the initial stakeholders.

It applies to

• product development,

• services (commonly to test willingness to pay),

• feature development (to gauge demand), and as

• differentiation (market test strategy).

Minimal approaches are frequently chosen based on time and money constraints.

Minimal Viable Product (MVP) enables iterative development cycles by collecting and analyzing feedback before delivering additional features.

MVP generally follows these three high level steps:

Step 1: determine the problem to be solved.

• Identify a hypothesis to solve this problem.

Step 2: identify a minimum set of features to test the hypothesis of the solution.

• Think about creative, low-cost options to test the hypothesis with the target market.

Step 3: analyze validated learning from customers to determine the next step.

• Gather feedback on feasibility of the solution and additional features needed to increase adoption.

Elements:

1. Target audience:

Business analysis practitioners clearly identify the target market and who will likely be the early adopters of the solution. Analysis of these groups identifies what problems they may have related to the proposed solution.

2. Goal to Achieve or Hypothesis to Test:

Business analysis practitioners clearly define the goal or the hypothesis to test with MVP.

For example, the hypothesis may suggest that the new product will lead to quick adoption with the target audience. Or, the organization may hypothesize that a new feature in a product will improve customer service.

3. Mechanism to Measure Learning:

In order to validate the hypothesis or to determine if the desired goal was achieved, business analysis practitioners identify objective measurements to correlate and interpret the feedback and learning received.

These measurements influence further solution development by identifying the success of the current MVP.

4. Defined Requirements:

Business analysis practitioners select the minimal amount of requirements necessary to deliver the MVP. This selection is based on the target audience, the goal to achieve, and the mechanism to measure learnings.

The amount of requirements necessary is subjective and dependent on context. There must be enough produced to validate the hypothesis; however, it must be the minimal amount to release the solution quickly.

Usage Considerations:

1. Strengths:

• It is less expensive than developing a product with more robust features.

• Reduces cost and risk by gaining customer feedback before engaging in a full solution.

• Avoids building products customers don’t want, thereby reducing risk.

• Tests actual usage scenario instead of relying on market research.

2. Limitations:

• Requires advanced market analysis to identify the necessary feature set for early adopters.

• There is no formula, and desired features are a best guess.

• It is not about creating a minimal product, but testing an initial hypothesis for a product.

• It is not useful for a clear or simple solution. For this situation, the defined Minimal Viable Product (MVP) is the complete product and should be considered as such.

Personas:

Purpose:

Personas are used to understand and empathize with an intended stakeholder in order to align the solution with the stakeholder need.

Description:

Personas are fictional characters or archetypes that exemplify the way that typical users interact with a solution. They are often used in agile approaches to understand value from the perspective of a particular stakeholder and allow a team that may not have direct access to a customer representative to better understand their needs. Work can then focus on the features of greatest value to a particular persona.

A persona is described as though it is real person. Personas may provide a name, personality, family, work background, skill level, preferences, behaviour patterns, personal attitudes, goals, and needs. They can also include a picture and a short “day in the life” narrative that helps to visualize the user and their experience.

Business analysis practitioners use personas to gain a deeper understanding of stakeholders than is generally provided from a role or actor description. Personas help improve a solution, a purpose, and usability because they are patterned after the subtle qualities of real people that will interact with the solution and how they do their job.

Personas are ranked to identify those that will realize the most benefit from the solution design.

Elements:

1. Long and Short Template:

Business analysis practitioners frequently use two different templates when creating personas:

• a short template which offers a one-page quick view of key information, and

• a long template which offers more in-depth details and understanding. Additional user research helps expand from short template to long template.

2. Persona Name and Image:

Business analysis practitioners give personas a realistic name and attach a fictional image in order increase its relatability and thereby the understanding of and empathy with the intended stakeholder.

3. Traits and Characteristics:

Personas include unique, distinguishing, and differentiating characteristics or traits regarding the intended stakeholder.

For example, one ATM persona may be an office manager who deposits cash at the end of the day. A different ATM persona may be an individual who likes to get small amounts out at a time.

4. Motivations:

Personas include a representation of the underlying motivations regarding how and why the intended stakeholder interacts with the solution.

For example, an ATM office manager may be motivated by reducing risk of fraud or theft. The individual withdrawing from the ATM may be motivated by withdrawing the minimum amount needed.

5. Needs:

Needs for the persona address very specific needs. These can be basic needs such as safety, trust, or access to food and shelter. They can be higher level needs such as the need for acceptance and validation. Needs are finite as compared to wants which are infinite.

6. Differentiators:

Differentiators identify specifically why this persona is different from another persona. They identify what is unique about this persona. These could be generational or experiential differentiators, preference differentiators, or identifying characteristics.

Usage Considerations:

1. Strengths:

• Personas facilitate the shared understanding of specific requirements for different sets of users. These requirements can be used to develop user stories.

• Proposed solutions can be guided by how well they meet the needs of individual user personas. Features can be prioritized based on how well they address the needs of one or more personas.

• Provide a human “face” so as to focus empathy on the people represented by the demographics.

• If the data is available, using demographic (or anthropomorphic) data about the intended user population is a good way to start building personas. However, it is based on little more than some cases it is necessary to be creative and invent personas few dry facts about the intended end users. In either case, a representative pool of personas should be identified.

Personas help stakeholders from projecting individual values and biases onto the solution. They help to develop compassion for various users.

2. Limitations:

• Personas are fictional, so there is a tendency to create personas that embody traits common to most users, but this creates a generic user that is not distinct or realistic. This can lead to solutions that are trying to be everything to everyone.

• Personas may not be a good substitute for a real user. Personas can distance a team from a user community.

• Personas need to be regularly reviewed and updated.

Portfolio Kanban:

Purpose:

Portfolio Kanban is used to manage the implementation of strategic initiatives by increasing visibility into the process, work-in-progress (WIP), decision making criteria, and feedback loops.

Description:

Kanban is a framework which helps in the application of agile values and principles. A portfolio is a collection of strategic initiatives for an organization or department to execute in alignment with their business goals. Portfolio Kanban brings structure to analysis and decision making at the Strategy Horizon.

Portfolio Kanban is a system to manage flow of work during the entire delivery cycle. It focuses on

• visualizing the work,

• limiting work-in-progress (WIP) to increase speed of delivery and reduce waste,

• managing flow by identifying bottlenecks and stalled items,

• making decision making and rules explicit,

• incorporating feedback loops, and

• increasing collaboration and continuous improvement.

The Kanban board visualizes the portfolio to show what initiatives are in progress, identify bottlenecks, and increase visibility to priorities, decision making, and feedback loops. Each portfolio initiative is represented as an item on the Kanban board. Items incorporate metrics or impact goals necessary for decision makers to prioritize initiatives and measure value against business goals.

Elements:

1. Kanban Board:

Columns of Kanban Board:

The columns of the Kanban board represent all the steps identified in the organization to move an initiative or item from idea to completion.

2. Done Criteria per Column:

For each column or step, there is an explicit criteria indicated when an item is complete and ready to move to the next column. This allows organizations to have a shared understanding of what must be completed to move to the next step.

3. Limits per Column:

Kanban emphasizes limiting work-in-progress to increase flow through the system. To effectively do this, organizations impose limits for each column based on the reasonable capacity of their departments or teams. The focus is on getting items through the portfolio in a timely manner over having many initiatives in progress without completion.

4. Strategic Business Initiatives or Portfolio Items:

Each strategic initiative is represented on the Kanban board as a portfolio item. Each item includes a name, short description, and metrics or impact goals to measure success.

5. Refinement Meeting:

Refinement meetings are used to make decisions and changes based on ongoing feedback and learning. Refinement meetings occur on a regular basis and include all necessary decision makers. Refinement meetings also include those affected by decisions such as product owners for each initiative. There is no standard format for this meeting; the outcomes include a review of the board, analysis of focus areas, and prioritization of existing items.

6. Metrics:

Each portfolio item includes impact metrics used to prioritize initiatives.

7. Visual:

One of the strengths of Kanban is providing values into the items on the board. The Portfolio Kanban board is made easily accessible to anyone who wants to view the information. Physical representations that can be easily interacted with have the greatest visibility and lowest barrier to entry.

Usage Considerations:

1. Strengths:

• Can be replicated at the Initiative and Delivery Horizons.

• Optimizes portfolio management to respond to business and customer needs.

• Increases feedback loop per portfolio item and per step.

• Increased visibility into work-in-progress allows people to see current priorities and focus for the organization.

• Increased visibility identifies bottlenecks or impediments which need support.

• Limiting work-in-progress increases overall flow of the system.

2. Limitations:

• Useful when all initiatives go through the same flow. It is not useful if there are different paths/columns through which an initiative can move.

• Initiatives should be appropriately sized to regularly move through columns. The approach does not add clarity when initiatives sit in the same column for a long period of time.

• Portfolio Kanban is designed to provide visibility. It is best used for a single flow system. Multiple systems represented on one Kanban board will be overwhelming and not provide the necessary clarity.

Situation

“I was, SAP Global Practice Area Head & Agile Coach - Advanced level, confronted with many different activities, like, handling Multiple Global Projects having Budget MORE THAN $ 400 Million USD, grooming CXO level business executives, Patent activities etc...”

Deeper Why

“I was able to sleep only 1 hour per day. It was overwhelming and it impacted my personal life and my health. My GOAL is to find happiness in life. Prioritize my daily Professional & Personal life tasks enabling me to perfectly maintain the Equilibrium between my Personal Life & Professional Life.”

Goal

–“Find happiness in life. Prioritize my daily Professional & Personal life tasks enabling me to perfectly maintain the Equilibrium between my Personal Life & Professional Life.”

Desired Outcome

The Personal Agility System brought in a new discipline to my life. It helps me not to miss important work, whether personal or professional. I update it every week and look at it every night to see that I did what I intended to do. I am able to sleep now 7 hours / Per day which was just 1 hour per day prior to PA workshop.

All my Family Members are happy using Personal Agility and it brings more disciplines in our life enabling us to become much happier, resilient & self-satisfied.

Having the agile mindset to continuously inspect and adapt by learning from all of you helps me in understanding how transformative the personal agility is in everyone's life.

Potential

More than 1000 Billion people are in similar situation now.

Achieved

“Personal Agility enables me to handle distractions, procrastination and helps me be more effective at work, happier in life, resilient. It helps me to figure out what really matters to bring me Closer to my Daily / Weekly / Monthly Goals or to Whom I want to be.

Personal Agility Forces Map Tool helps me to organize and Prioritize TO-DO's according to WHAT really matters.

Personal Agility Stakeholder Canvas Tool helps me to figure out What really matters to my Stakeholders enabling me to meet Stakeholders expectations and to enhance Stakeholders delight.”

Tools

“The below tools and techniques of the Personal Agility System helped me achieving my desired outcome:

•What Really Matters (WRM)

•Life is the ocean” metaphor

•The 6 Questions of PAS

•Celebrate and Choose Event

•PAS Priorities Map and Breadcrumb Trail

•PAS Forces Map

•PAS Alignment Compass

•PAS Stakeholder Canvas.”

How

“Personal Agility enables me to handle distractions, procrastination and helps me be more effective at work, happier in life, resilient. It helps me to figure out what really matters to bring me Closer to my Daily / Weekly / Monthly Goals or to Whom I want to be.

Personal Agility Forces Map Tool helps me to organize and Prioritize TO-DO's according to WHAT really matters.

Personal Agility Stakeholder Canvas Tool helps me to figure out What really matters to my Stakeholders enabling me to meet Stakeholders expectations and to enhance Stakeholders delight..”

What else

“Having the agile mindset to continuously inspect and adapt by learning from all of you helps me in understanding how transformative the personal agility is in everyone's life.

If agility means change for everyone else except you, you have started on the wrong foot. Personal agility is the one that helps you to find navigations to "What really matters".

PAS acted as Fuel to the fire and ignited back my quest for Health.

View the below Linkedin Blog to know more

URL - https://personalagilityinstitute.org/community/first-book-applying-personal-agility/reignite-yourself-using-personal-emotional-agility-make-it-your-daily-habit/#post-548

https://www.linkedin.com/pulse/reignite-yourself-using-personal-emotional-agility-/

.”

Why Scrum?

We first created Scrum, with Ken Schwaber, twenty years ago, as a faster, more reliable, more effective way to create software in the tech industry. Up to that point and even as late as 2005—most software development projects were created using the Waterfall method, where a project was completed in distinct stages and moved step by step toward ultimate release to consumers or software users. The process was slow, unpredictable, and often never resulted in a product that people wanted or would pay to buy. Delays of months or even years were endemic to the process. The early step-by-step plans, laid out in comforting detail in Gantt charts, reassured management that we were in control of the development process—but almost without fail, we would fall quickly behind schedule and disastrously over budget.

To overcome those faults, in 1993 we invented a new way of doing things: Scrum.

It is a radical change from the prescriptive, top-down project management methodologies of the past. Scrum, instead, is akin to evolutionary, adaptive, and self-correcting systems. Since its inception, the Scrum framework has become the way the tech industry creates new software and products. But while Scrum has become famously successful in managing software and hardware projects in Silicon Valley, it remains relatively unknown in general business practice. And that is why we wrote Scrum: to reveal and explain the Scrum management system to businesses outside the world of technology. In the tutorial we talk about the origins of Scrum in the Toyota Production System and the OODA loop of combat aviation. We discuss how we organize projects around small teams—and why that is such an effective way to work. We explain how we prioritize projects, how we set up one-week to one-month “sprints” to gain momentum and hold everyone on the team accountable, how we conduct brief daily stand-ups to keep tabs on what has been done and on the challenges that have inevitably cropped up. And how Scrum incorporates the concepts of continuous improvement and minimum viable products to get immediate feedback from consumers, rather than waiting until a project is finished. As you’ll see in the pages that follow, we’ve used Scrum to build everything from affordable 100-mile-pergallon cars to bringing the FBI database systems into the twenty-first century.

Read on. We think you’ll see how Scrum can help transform how your company works, creates, plans, and thinks. We firmly believe that Scrum can help to revolutionize how business works in virtually every industry, just as it has revolutionized innovation and speed to market at a dazzling array of new companies and a breathtaking range of new products emerging out of Silicon Valley and the world of technology.

IMPLEMENTING SCRUM - HOW TO BEGIN:

Now that you’ve read the book, here’s how to start a Scrum project in a nutshell. This is a very broad stroke description of the process, but it should be enough to get you started. The book was written to give you the why behind Scrum. This will, in an abbreviated form, give you the how.

1. Pick a Product Owner. This person is the one with the vision of what you are going to do, make, or accomplish. They take into account risks and rewards, what is possible, what can be done, and what they are passionate about. (See Chapter Eight: Priorities for more.).

2. Pick a Team. Who will be the people actually doing the work? This team needs to have all the skills needed to take the Product Owners’ vision and make it a reality. Teams should be small, 3 to 9 people is the rule of thumb. (See Chapter Three: Teams for more.).

3. Pick a Scrum Master. This is the person who will coach the rest of the team through the Scrum framework, and help the team eliminate anything that is slowing them down. (See Chapter Four: Waste for more.).

4. Create and prioritize a Product Backlog. This is a list at a high level of everything that needs to be built or done to make that vision a reality. This backlog exists and evolves over the lifetime of the product; it is the product roadmap. At any point, the Product Backlog is the single, definitive view of “everything that could be done by the team ever, in order of priority.” Only a single Product Backlog exists; this means the Product Owner is required to make prioritization decisions across the entire spectrum. The Product Owner should consult with all stakeholders and the team to make sure they are representing both what people want and what can be built. (See Chapter Eight: Priorities for more.).

5. Refine and Estimate the Product Backlog. It is crucial that the people who are actually going to complete the items in the Product Backlog estimate how much effort they will take. The team should look at each Backlog item, and see if it is actually doable. Is there enough information to complete the item? Is it small enough to estimate? Is there a Definition of Done, that is, everyone agrees on what standards must be met to call something “done”? Does it create visible value? Each item must be able to be shown, to be demonstrated, hopefully to be potentially shippable. Do not estimate the Backlog in hours, because people are absolutely terrible at that. Estimate by relative size: Small, Medium, or Large. Or even better use the Fibonacci sequence and estimate the point value for each item: 1, 2, 3, 5, 8, 13, 21, etc. (See Chapter Six: Plan Reality, Not Fantasy for more.)

6. Sprint Planning. This is the first of the Scrum meetings. The team, the Scrum Master, and the Product Owner sit down to plan the Sprint. Sprints are always a fixed length of time that is less than a month. Most people now run one or two week Sprints. The team looks at the top of the Backlog and forecasts how much of it they can complete in this Sprint. If the team has been going for a few Sprints, they should take in the number of points they did in the last Sprint. That number is known as the team’s Velocity. The Scrum Master and the team should be trying to increase that number every Sprint. This is another chance for the team and the Product Owner to make sure that everyone understands exactly how these items are going to fulfill the vision. Also during this meeting everyone should agree on a Sprint Goal, what everyone wants to accomplish with this Sprint.

One of the pillars of Scrum is that once the team has committed to what they think they can finish in one Sprint, that’s it. It cannot be changed, it cannot be added to. The team must be able to work autonomously throughout the Sprint to complete what they forecast they could. (See Chapter Four: Time and Chapter Six: Plan Reality, Not Fantasy for more.)

7. Make Work Visible. The most common way to do this in Scrum is to create a Scrum Board with three columns: To Do, Doing, Done. Sticky notes represent the items to be completed and the team moves them across the Scrum board as they are completed, one by one.

Another way to make work visible is to create a Burndown Chart. On one axis is the number of points the team has taken into the Sprint, on the other is the number of days. Every day the Scrum Master tallies up the number of points completed and graphs them on the Burndown chart. Ideally there will be a steep downward slope leading to zero points left on the last day of the Sprint. (See Chapter Seven: Happiness for more.)

8. Daily Stand-up or Daily Scrum. This is the heartbeat of Scrum. Each day, at the same time, for no more than fifteen minutes, the team and the Scrum Master meet and answer three questions:

• What did you do yesterday to help the team finish the Sprint?

• What will you do today to help the team finish the Sprint?

• Is there any obstacle blocking you or the team from achieving the Sprint Goal?

That’s it. That’s the whole meeting. If it takes more than fifteen minutes, you’re doing it wrong. What this does is help the whole team know exactly where everything is in the Sprint. Are all the tasks going to be completed on time? Are there opportunities to help other team members overcome obstacles? There’s no assigning of tasks from above—the team is autonomous; they do that. There’s no detailed reporting to management. The Scrum Master is responsible for making the obstacles to the team’s progress, or impediments, go away. (See Chapter Four: Time and Chapter Six: Plan Reality, Not Fantasy for more.)

9. Sprint Review or Sprint Demo. This is the meeting where the team shows what they have accomplished during the Sprint. Anyone can come, not only the Product Owner, the Scrum Master, and the team, but stakeholders, management, customers, whoever. This is an open meeting where the team demonstrates what they were able to move to Done during the Sprint.

The team should only demo what meets the Definition of Done. What is totally and completely finished and can be delivered without any more work. It may not be a completed product, but it should be a completed feature of one. (See Chapter Four: Time for more.)

10. Sprint Retrospective. After the team has shown what they’ve accomplished during the last Sprint—that thing that is “done” and can potentially be shipped to customers for feedback—they sit down and think about what went right, what could have gone better, and what can be made better in the next Sprint. What is the improvement in the process that they, as a team, can implement right away?

To be effective, this meeting requires a certain amount of emotional maturity and an atmosphere of trust. The key thing to remember is that you’re not seeking someone to blame; you’re looking at the process. Why did that happen that way? Why did we miss that? What could make us faster? It is crucial that people as a team take responsibility for their process and outcomes, and seek solutions as a team. At the same time, people have to have the fortitude to bring up the issues that are really bothering them in a way that is solution oriented rather than accusatory. And the rest of the team has to have the maturity to hear the feedback, take it in, and look for a solution rather than getting defensive.

By the end of the meeting the team and the Scrum Master should agree on one process improvement that they will implement in the next Sprint.

That process improvement, sometimes called the kaizen, should be put into the next Sprint’s backlog, with acceptance tests. That way the team can easily see if they actually implemented the improvement, and what effect it had on velocity. (See Chapter Seven: Happiness for more.)

11. Immediately start the next Sprint cycle, taking the Team’s experience with impediments and process improvements into account.

Scrum Master Anti-Patterns are

1. My Scrum Master has never been on a Scrum Team but he took a class.

2. My Scrum Master has never heard about Extreme Programming.

3. My Scrum Master proposed that we separate out the Test team so they would be more efficient.

4. My Scrum Master can't really explain story points to us.

5. My Scrum Master has Ken Schwaber's book on his desk and says he will read it soon.

6. My Scrum Master can't really explain to me why we are using Scrum.

7. My Scrum Master can't explain our plan for rolling out Scrum to our Teams.

8. My Scrum Master tells me we don't have the resources to get training in Scrum.

9. My Scrum Master always makes us use the proper Scrum terms to describe what we are doing.

10. My Scrum Master showed up on the first day with an adapted Scrum process for us to follow.

11. My Scrum Master develops the high level release plans with our CEO so that we know our due date.

12. My Scrum Master told the VP Marketing to interrupt me during the sprint to work on something for him.

13. My Scrum Master demonstrates our progress to the stakeholders in an offline meeting.

14. My Scrum Master thinks it is best to keep some of our development challenges to ourselves.

15. My Scrum Master isn't here right now, he is working with another team.

16. My Scrum Master is my Manager.

17. My Scrum Master assigns me work or tasks.

18. My Scrum Master also performs the role of my Product Owner.

19. My Scrum Master isn't here right now, he is in the VP's weekly status meeting.

20. My Scrum Master doesn't really understand what I am working on.

21. My Scrum Master missed our Sprint planning meeting to attend a "Dress for Success" seminar.

22. My Scrum Master is busy writing code.

23. My Scrum Master sits in for our Product Owner in our planning meeting.

24. My Scrum Master brings us our Sprint goals from the VP.

25. My Scrum Master only decides the release planning, but never discusses with Product Owner.

26. My Scrum Master only cancels the Sprint if it is no longer required by market, but never discusses with Product Owner.

27. My Scrum Master develops and conducts the demo for sprint review.

28. My Scrum Master never goes to lunch with us.

29. My Scrum Master always points out our limits and what we can't do.

30. My Scrum Master gets impatient when we are making decisions and makes the call for us.

31. My Scrum Master told us we should use JUnit, and even installed it for us.

32. My Scrum Master gives us a hard time when we try to adjust our work during the Sprint.

33. My Scrum Master runs our daily status meeting.

34. My Scrum Master updates our sprint tracking info.

35. My Scrum Master is always scrambling to get the conference call set up for the daily Scrum.

36. My Scrum Master needs to approve any of our decisions that affect our sprint plan.

37. My Scrum Master relays our status and needs the other Scrum teams help on our project.

38. My Scrum Master says it's OK when no Stakeholders show up for our sprint review.

39. My Scrum Master said it's OK to leave the testing of this story to next sprint.

40. My Scrum Master doesn't think we need a published definition of done.

41. My Scrum Master says it's OK to avoid a few trouble spots and not talk about them during the sprint review demo.

42. My Scrum Master seems to argue a lot with our VP and senior managers.

43. My Scrum Master is afraid to tell our CEO that we can't hit our due date.

44. My Scrum Master said it's OK for us to ignore our corporate coding standards because we are a Scrum Team.

45. My Scrum Master says it's OK for us to use our own version of Scrum, different from the other teams.

46. My Scrum Master never works as a link to the organization.

48. My Scrum Master never promotes and facilitates transparency and the flow of honest feedback.

49. My Scrum Master never understands the larger organizational picture.

50. My Scrum Master never actively removes impediments.

51. My Scrum Master never coaches and works at team building.

52. My Scrum Master never works as a Change agent to lead the transition.

53. My Scrum Master never an accountable Scrum Master.

54. My Scrum Master never reads and understands the new Scrum Guide 2020.

55. My Scrum Master never keeps himself up-to-date on Scrum progress. 

THE TAKEAWAYs are

Fail Fast So You Can Fix Early. Corporate culture often puts more weight on forms, procedures, and meetings than on visible value creation that can be inspected at short intervals by users. Work that does not produce real value is madness. Working product in short cycles allows early user feedback and you can immediately eliminate what is obviously wasteful effort.

Hesitation Is Death. Observe, Orient, Decide, Act. Know where you are, assess your options, make a decision, and act!

Planning Is Useful. Blindly Following Plans Is Stupid. It’s just so tempting to draw up endless charts. All the work needed to be done on a massive project laid out for everyone to see—but when detailed plans meet reality, they fall apart. Build into your working method the assumption of change, discovery, and new ideas.

Inspect and Adapt. Every little while, stop doing what you’re doing, review what you’ve done, and see if it’s still what you should be doing and if you can do it better.

Change or Die. Clinging to the old way of doing things, of command and control and rigid predictability, will bring only failure. In the meantime, the competition that is willing to change will leave you in the dust.

Look Outward for Answers. Complex adaptive systems follow a few simple rules, which they learn from their environment.

Great Teams Are. They are cross-functional, autonomous, and empowered, with a transcendent purpose.

Don’t Guess. Plan, Do, Check, Act. Plan what you’re going to do. Do it.

Check whether it did what you wanted. Act on that and change how you’re doing things. Repeat in regular cycles, and, by doing so, achieve continuous improvement.

Shu Ha Ri. First, learn the rules and the forms, and once you’ve mastered them, make innovations. Finally, in a heightened state of mastery, discard the forms and just be—with all the learning internalized and decisions made almost unconsciously.

Pull the Right Lever. Change Team performance. That has much more impact by several orders of magnitude—than individual performance.

Transcendence. Great teams have a purpose that is greater than the individual; e.g., burying General MacArthur, winning the NBA championship.

Autonomy. Give teams the freedom to make decisions on how to take action to be respected as masters of their craft. The ability to improvise will make all the difference, whether the unit is reporting on a revolution in the Middle East or making a sale.

Cross-functional. The team must have every skill needed to complete a project, whether the mission is to deliver Salesforce.com software or capture terrorists in Iraq.

Small Wins. Small teams get work done faster than big teams. The rule of thumb is seven team members—plus or minus two. Err on the small side.

Blame Is Stupid. Don’t look for bad people; look for bad systems, ones that incentivize bad behavior and reward poor performance.

Time Is Finite. Treat It That Way. Break down your work into what can be accomplished in a regular, set, short period, optimally one to four weeks. And if you’ve caught the Scrum fever, call it a Sprint.

Demo or Die. At the end of each Sprint, have something that’s done, something that can be used (to fly, drive, whatever).

Throw Away Your Business Cards. Titles are specialized status markers.

Be known for what you do, not how you’re referred to.

Everyone Knows Everything. Communication saturation accelerates work.

One Meeting a Day. When it comes to team check-ins, once a day is enough. Get together for fifteen minutes at the Daily Stand-up, see what can be done to increase speed, and do it.

Multitasking Makes You Stupid. Doing more than one thing at a time makes you slower and worse at both tasks. Don’t do it. If you think this doesn’t apply to you, you’re wrong—it does.

Half-Done Is Not Done. A half-built car simply ties up resources that could be used to create value or save money. Anything that’s “in process” costs money and energy without delivering anything.

Do It Right the First Time. When you make a mistake, fix it right away.

Stop everything else and address it. Fixing it later can take you more than twenty times longer than if you fix it now.

Working Too Hard Only Makes More Work. Working long hours doesn’t get more done; it gets less done. Working too much results in fatigue, which leads to errors, which leads to having to fix the thing you just finished.

Rather than work late or on the weekends, work weekdays only at a sustainable pace. And take a vacation.

Don’t Be Unreasonable. Goals that are challenging are motivators; goals that are impossible are just depressing.

No Heroics. If you need a hero to get things done, you have a problem.

Heroic effort should be viewed as a failure of planning.

Work Is a Story. Think first about who’ll be getting value from something, then about what it is, and then why they need it. Humans think in narratives, so give them one. As an X, I want Y, so that Z.

Know Your Velocity. Every team should know exactly how much work they can get done in each Sprint. And they should know how much they can improve that velocity by working smarter and removing barriers that are slowing them down.

Velocity × Time = Delivery. Once you know how fast you’re going, you’ll know how soon you’ll get there.

Set Audacious Goals. With Scrum it is not that hard to double production or cut delivery time in half. If you do it in the right way, your revenue and stock price should double as well.

It’s the Journey, Not the Destination. True happiness is found in the process, not the result. Often we only reward results, but what we really want to reward is people striving toward greatness.

Happy Is the New Black. It helps you make smarter decisions. Plus, when you’re happy, you’re more creative, less likely to leave your job, and more likely to accomplish far more than you ever anticipated.

Additional KEY TAKEAWAYs are

Quantify Happiness. It’s not enough just to feel good; you need to measure that feeling and compare it to actual performance. Other metrics look backward. Happiness is a future-looking metric.

Get Better Every Day—and Measure It. At the end of each Sprint, the team should pick one small improvement, or kaizen, that will make them happier. And that should become the most important thing they’ll accomplish in the next Sprint.

Secrecy Is Poison. Nothing should be secret. Everyone should know everything, and that includes salaries and financials. Obfuscation only

serves people who serve themselves.

Make Work Visible. Have a board that shows all the work that needs to be done, what is being worked on, and what is actually done. Everyone should see it, and everyone should update it every day.

Happiness Is Autonomy, Mastery, and Purpose. Everyone wants to control their own destiny, get better at what they do, and serve a purpose greater than themselves.

Pop the Happy Bubble. Don’t get so happy that you start believing your own bullshit. Make sure happiness is measured against performance, and if there is a disconnect, be prepared to act. Complacency is the enemy of success.

Make a List. Check It Twice. Create a list of everything that could possibly be done on a project. Then prioritize it. Put the items with the highest value and lowest risk at the top of that Backlog, then the next, and then the next.

The Product Owner. She translates vision into Backlog. She needs to understand the business case, the market, and the customer.

A Leader Isn’t a Boss. A Product Owner sets out what needs to be done and why. How the team accomplishes it and who accomplishes it is up to the team.

The Product Owner: Has knowledge of the domain and the power to make final decisions. He or she is available to answer questions and is accountable for delivering value.

Observe, Orient, Decide, Act (OODA). See the whole strategic picture, but act tactically and quickly.

Fear, Uncertainty, and Doubt. It’s better to give than to receive. Get inside your competition’s OODA loop and wrap them up in their own confusion.

Get Your Money for Nothing, and Your Change for Free. Create new things only as long as those new things deliver value. Be willing to swap them out for things that require equal effort. What in the beginning you thought you needed is never what is actually needed.

Scrum Accelerates All Human Endeavors. The type of project or problem doesn’t matter—Scrum can be used in any endeavor to improve performance and results.

Scrum for Schools. In the Netherlands, a growing number of teachers are using Scrum to teach high school. They see an almost immediate improvement in test scores of more than 10 percent.

And they’re engaging all sorts of students, from vocational to gifted.

Scrum for Poverty. In Uganda, the Grameen Foundation is using Scrum to deliver agricultural and market data to poor rural farmers. The result:

double the yield and double the revenue for some of the poorest people on the planet.

Rip Up Your Business Cards. Get rid of all titles, all managers, all structures. Give people the freedom to do what they think best and the responsibility to be accountable for it. You’ll be surprised at the results.

Enough with the Stupid Policies. Any policy that seems ridiculous likely is. Stupid forms, stupid meetings, stupid approvals, stupid standards are just that—stupid. If your office seems like a Dilbert cartoon, fix it.

Don’t be one, and don’t allow the behavior. Anyone who causes emotional chaos, inspires fear or dread, or demeans or diminishes people needs to be stopped cold.

Strive for Flow. Choose the smoothest, most trouble-free way to get things done. Scrum is about enabling the most flow possible.

The Map Is Not the Terrain. Don’t fall in love with your plan. It’s almost certainly wrong.

Only Plan What You Need To. Don’t try to project everything out years in advance. Just plan enough to keep your teams busy.

What Kind of Dog Is It? Don’t estimate in absolute terms like hours—it’s been proven that humans are terrible at that. Size things relatively, by what breed of dog the problem is, or T-shirt size (S, M, L, XL, XXL), or, more commonly, the Fibonacci sequence.

Ask the Oracle. Use a blind technique, like the Delphi method, to avoid anchoring biases such as the halo effect or bandwagon effect or just plain stupid groupthink.

Plan with Poker. Use Planning Poker to quickly estimate work that needs to be done.

Solving a client’s issue may require many complex work streams, so we set up a sprint...It’s a way of getting people to be collaborative, take accountability and feel empowered.

- Tamara Ingram

Chief Executive Officer,

J. Walter Thompson Company

Let's begin this progressive journey together.

"Everybody wants to Change the World. But they never think about changing Themselves".

"Personal Agility is a GREAT framework to help you figure out what really matters to bring you Closer to your Daily / Weekly / Monthly Goals or to Whom you want to be.

Inner Self Satisfaction, REJOICE THE JOURNEY and Celebrate your SUCCESS is the happiness key lever".

-SUDIPTA MALAKAR – Best Selling Author, International Coach & Speaker-

Agile Application Lifecycle Management, also called Agile ALM, Agile Application Lifecycle Management is the integrated management platform of the entire software application lifecycle, from planning to the final release. Key components of the platform include the ability to handle change management, workflow, source code management, task management, testing and bug tracking, reporting and analytics.

Agile practices are procedures that are defined as being highly efficient to productivity, and include the following practices: user stories, cross-functional teams, unit testing, refactoring, continuous integration, multi-stage continuous integration, planning poker, burnup charts, burndown charts.

Agile development is a way of thinking about software development as expressed in the Agile Manifesto, and acts as an “umbrella” for a group of methodologies. The methodologies are based on process-centric and iterative development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. Agile development is a conceptual framework that promotes evolutionary change throughout the entire life cycle of the project and represents a new, more flexible approach to development than the traditional methods that have previously been the norm for software development.

Agile Development Life Cycle is the complete software development process including Agile practices such as user stories, cross-functional teams, unit testing, refactoring, continuous integration, multi-stage continuous integration, planning poker, burnup charts, burndown charts.

Agile Manifesto is Principles of Agile software development: "We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

- Individuals and interactions over processes and tools

- Working software over comprehensive documentation

- Customer collaboration over contract negotiation

- Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.”

Agile process is a software development methodology based on process-centric and iterative development, where requirements and solutions evolve through collaboration between self-organizing cross-functional teams and is collectively regarded as highly efficient to productivity. Specific processes include user stories, cross functional teams, unit testing, refactoring, continuous integration, multi-stage continuous integration, planning poker, burnup charts and burndown charts.

Agile project management is the process of planning, organizing, and managing the necessary resources in order to complete project goals while adhering to Agile practices.

Agile SCM tool is Software Configuration Management tool that supports Agile Software Development Lifecycle requirements differently than requirements involved with traditional software development. These supported features and requirements of Agile SCM include feature-oriented development, sandboxing with private build before check-in, ability to revert to last good working version when integration testing fails, staging hierarchy, ability to revert and retarget changes, refactoring support and support for geographically distributed development.

Agile software development is a way of thinking about software development, as expressed in the Agile Manifesto, and acts as an “umbrella” for a group of methodologies.

The methodologies are based on process-centric and iterative development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. Agile software development is a conceptual framework that promotes evolutionary change throughout the entire life cycle of the project and represents a new, more flexible approach to development than the traditional methods that have been the norm for software development.

Application development Process Tools are necessary to complete the application development process, such as Application Lifecycle Management tools, Software Configuration Management tools, Build and Release tools, security and defect tracking tools, etc.

ALM, Application Lifecycle Management is the management platform of the entire software application lifecycle, from planning to the final release. Key components of the platform include the ability to handle change management, workflow, source code management, task management, testing and bug tracking, reporting and analytics.

"Product backlog," the backlog is a prioritized list of user stories and defects in order from most valuable to least valuable for a system. Backlogs include both functional and non-functional user stories as well as technical team-generated stories.

Branching is the duplication of objects under revision control (such as a source code file, or a directory tree) in such a way that the newly created objects initially have the same content as the original, but can evolve independently of the original. Branching can take two forms, static or dynamic. In static branches, copy and label operations are used to duplicate a given branch. The duplicate then can evolve independently. With dynamic branches, usually implemented in streams, only the label operation is used, to flag the point in time that a stream diverged from its parent stream. Both branching forms support some form of merging, so that code changes made on a branch can be re-integrated into another branch, as is typical in parallel development processes.

Burndown chart is the Representation of the number of hours remaining for completion of a project; usually represented in chart form with points plotted on an x and y axis that map a downward trend of work left to do until burning down to zero.

Burnup chart is the Representation of the number of stories completed; usually represented in chart form with points plotted on an x and y axis that map an upward trend of work completed until reaching 100%.

Change and Configuration Management (also known as Software Change and Configuration Management or SCCM) combines aspects of both change management and configuration management to control a software development project as it evolves through the software development process. SCCM typically includes all technical aspects of the development process, such as version control, branching and merging.

Additionally, SCCM includes change related activities such as issue tracking, document tracking, and process workflows that enable development teams to control the overall process.

Change control is the Process in which changes to a product or system are introduced in a controlled manner with minimal disruptions to services and cost effective solutions involved in implementing the changes.

Change Management enables development organizations to control, communicate and respond more effectively to rapidly changing business demands.

Change Packages enable developers and managers to group file changes together into a logical whole and enable release managers to work at the issue or task level, while still providing developers with full access to the underlying file contents of the Change Package.

Once created, a Change Package allows users to move, copy, modify, merge or revert the change package.

Collocation refers to development teams located and working in the same location.

Collocation is usually applied at the cross-functional team level.

Configuration Management refers to a set of practices around storing, tracking and releasing versions of a software product. Software products that enable development organizations to perform these practices efficiently are also referred to as Configuration Management systems or Configuration Management tools. Configuration Management systems will typically provide users with a variety of features, including but not limited to source code control, issue tracking, and change set management.

Configuration Management tools are the tools that make possible the practices around storing, tracking and releasing versions of software.

Continuous integration, one of the foundational aspects of Agile software development methodologies, is defined by Martin Fowler to be "a fully automated and reproducible build, including testing, that runs many times a day. This allows each developer to integrate daily, thus reducing integration problems." By getting changes into the main line as frequently as possible, preferably daily, and by extending the idea of a nightly build, continuous integration helps reduce integrations problems and identify and resolve problems more quickly.

Cross-Functional Team comprised of members with all functional skills and specialties necessary to complete a project from start to finish.

Distributed Development teams that work on the same project but are located across multiple locations or worksites.

The adoption of specific Agile practices in an organization that works in conjunction with other non-Agile practices. Enterprise Agile is a highly efficient and customized practice for large organizations that have difficulty making a complete transition to Agile, as well as for organizations that already practice efficient development processes.

Epic is a user story which describes a large amount of customer value and needs to be broken down into many smaller user stories.

Feature Driven Development (FDD) is an Agile method for developing software based on an iterative and incremental software development process. The main purpose of FDD is to deliver tangible, working software repeatedly in a timely manner.

Hybrid process is a Development process that uses both Agile and non-Agile practices in conjunction with each other and is proven highly effective for development teams.

Agile process where teams evaluate a project by looking, listening to each other’s feedback and ultimately improving the process or changing course. It is called inspection and adapting.

Microcosm of a traditional Systems Development Life Cycle (SDLC,) each of which produces working software. Iterations can be as large as 3 months but are more typically between 1 to 4 weeks. It is abbreviated as iteration.

Kanban is a Methodology that comes from Lean software development and has three main components:

visual system for managing work, limits work in progress, and work is pulled rather than pushed through the system.

Lean Software development is A programming concept that focuses on optimizing efficiencies for development and

minimizing waste. According to Mary Poppendieck, 10 rules of Lean programming include:

- eliminate waste,

- minimize artifacts,

- satisfy all stakeholders,

- deliver as fast as possible,

- decide as late as possible,

- decide as low as possible,

- deploy comprehensive testing,

- learn by experimentation,

- measure business impact and

- optimize across organizations.

Merging is the process of incorporating branches back into the mainline.

Agile method allowing for a high degree of integration to occur in parallel while vastly reducing the scope of integration problems. Multi-stage Continuous Integration (CI) is an expansion upon Continuous Integration, where each developer works on his or her own task. As changes are made, CI is done against that team's branch. If CI does not succeed, then that developer (possibly with help from her teammates) fixes the branch. This way when there is a problem, only that team, not the whole development effort is affected. It is abbreviated as Multi-stage Continuous integration.

One Piece flow is a process in which each developer or development process works on only one piece at a time before pulling code downstream, one piece at a time, to the next process.

Pair Programming is a process in which two developers work together at a single workstation, where one is responsible for typing code and the other for reviewing each line of code as it is typed in.

Parallel development occurs whenever a software development project requires separate development efforts on related code bases. For example, when a software product is shipped to customers, a product development team may begin working on a new major feature release of the product, while a product maintenance team may work on defect corrections and customer patch releases of the shipped product. Both teams begin work from the same code base, but the code necessarily diverges. Frequently the code bases used in parallel development efforts must be merged at some future date, for example, to ensure that the defect corrections provided by the product maintenance team are integrated into the major release that the product development team is working on.

Planning Poker is a consensus-based technique for estimating; mostly used to estimate effort or relative size of tasks in software development. Planning Poker is useful for building team cohesion and for fostering self-organizing teams.

Product backlog is the backlog owned by the Product Owner.

Product owner is a role originating from Scrum, but has now been widely adopted independently of Scrum.

A product owner manages the product backlog, addresses questions that arise during development and signs off on work results. The product owner guides the team with what should be done and when the final product should be shipped. The Scrum team then balances out the product owner’s decisions by deciding how much work should be involved in an individual sprint and estimating the amount of time necessary to complete the task.

The adoption of specific Agile practices in an organization that works in conjunction with other non-Agile practices. Real World Agile is a highly efficient and customized practice for large organizations that have difficulty make a complete transition to Agile as well as for organizations that already practice efficient development processes.

Refactoring is the practice of continuously improving the usability, maintainability, and adaptability of code without changing its behavior. Refactoring makes it much easier to add new and unanticipated functionality. Refactoring has the disadvantage that it takes extra effort and requires changing the code.

Release management comprises a broad set of activities in software development organizations that center on ensuring that software is ready to be released to customers.

Release plan is a document describing scheduling, activities, resources and responsibilities related to a particular release.

The software release process is the final stage in a typical software development effort, where the software product is made available for use. To ready a software product for release, the release process must ensure that all product requirements have been met, usually by executing test suites designed to exercise product functionality and correcting any defects found.

Software Configuration Management software is a software tool that enable organizations

to perform the SCM practices of storing, tracking and releasing a product, and typically

provide users with a variety of features including source code control, issue tracking and

change set management, advanced configuration management, change packages, process

management and integrated issue tracking.

Software Configuration Management tools are tools that enable organizations to perform

SCM practices and typically provide users with a variety of features, including source code

control, issue tracking and change set management, advanced configuration management,

change packages, process management and integrated issue tracking.

Scrum is Agile development project management framework based around sprints and is generally

comprised of a Scrum Team, Product Owner and Scrum Master. The framework of Scrum

leaves most development decisions up to the self-organizing Scrum team, where decisions

are reached as a whole team.

Scrum Master is a Person trained to facilitate daily Scrum meetings, remove impediments, oversee the team’s

progress through the process and track Scrum team updates.

Self-organizing is A team, usually found in Scrum, that manages itself through various means of

communication and reoccurring structured meetings. Self organizing teams solve

development issues together as a whole and decide the best solution depending on the

various team members.

Software change and configuration management (SCCM) combines aspects of both change

management and configuration management to control a software development project as

it evolves through the software development process. SCCM typically includes all technical

aspects of the development process, such as version control, branching and merging.

Additionally, SCCM includes change related activities such as issue tracking, document

tracking, and process workflows that enable development teams to control the overall

process.

Software Configuration Management (SCM) refers to a set of practices around storing,

tracking and releasing versions of a software product. Software products that enable

development organizations to perform these practices efficiently are also referred to as

Software Configuration Management systems or Software Configuration Management tools.

Software Configuration Management systems will typically provide users with a variety of

features, including but not limited to: source code control, issue tracking and change set

management.

Software development is the development of software in a planned and structured process. See software development

process.

The software development process is the set of coordinated activities performed by

engineers, managers and technical writers resulting in the creation of a software product.

Various named software development processes are in use today, including Agile, XP,

Scrum, Waterfall and Lean.

Source code control is a common requirement in all modern software development projects

that provides mechanisms for checking source code in and out of a central repository. This

allows different developers to work on the same project, with reduced fears of lost code

or overwritten changes. Source code control also implies a version control system that

can manage files through the development lifecycle, keeping track of which changes were

made, who made them, when they were made, and why. Finally, source code control also

frequently involves the ability to group versioned files as a single release, maintain multiple

active releases concurrently (branching), and join different releases (merging).

Source code management refers broadly to the set of operations required to store, retrieve

and version the files used to construct software applications. Development teams rely

on source code management to organize the source code files for different releases of

software, so that releases can be uniquely identified for testing, packaging and delivery to

customers. Failure to do this properly results in poor quality releases and inefficient use of

Spike is Timeboxed investigation of feasibility via a bare bones implementation, which touches on all

aspects of the full implementation.

Sprint is Scrum specific word describing iterations.

Sprint Backlog is the Plan for development team to map out implementation of features for an upcoming sprint.

Sprint planning is a meeting for Scrum Teams, Scrum Masters and Product Owners where the Product Owner

describes priority features to the team. The Scrum Team gets enough of an understanding

about the tasks discussed that they are able to choose which ones to move from the

product backlog to the sprint backlog.

Retrospective is a Meeting held at the end of every sprint review to reflect on what went well during the sprint

and what can be improved upon during the next sprint. Sprint retrospectives are valued as

necessary parts of inspecting and adapting, and allow development teams to plan for future

output.

In the sprint review, teams go over what stories were completed during the iteration and

demonstrate those stories for stakeholders and the product owner.

Daily Meetings that are meant to quickly and efficiently resolve obstacles that any team

members may be experiencing.

Story points are Relative scale of effort required by a team to implement a user story.

Task board is a physical or electronic board representing the state of tasks in a current sprint, often

divided into "to do," "in progress" and "done."

Timeboxing is The practice of constraining the amount of time for performing any activity. Examples

include iterations, spikes and stand up meetings.

Unit testing are Tests that exercise small amounts of isolated functionality.

User stories are Used with Agile methodologies for specifying requirements and presented as an informal

statement of the requirement (usually fitting on a 3x5 index card).

The velocity of a team is the number of story points associated with stories that are finished

over a given period of time, often 1 to 4 weeks. For instance, if the team completed 8 stories

that were each 5 points during a four week period, then their velocity is 40 story points every

four weeks.

Waterfall is the Model of a software development process in which progress flows downwards through

phases of conception, initiation, analysis, design, construction, testing and maintenance.

Whole Team comprised of members with different functional skills and specialties that work

together during all phases of development in order to complete a project from start to finish.

Also known as a cross-functional team.

"Extreme Programming," one implementation of the Agile methodology that focuses on

producing the simplest coding situation for application requirements and includes practices

such as pair programming, incremental design and continuous integration.

Scrum Guide 2020 - The Changes

Key Points:

- Scrum is still Scrum.

- One Team, One Product.

- More focused, more inclusive, less prescriptive.

- More focus on value and goals.

- Now only 14 pages.

Scrum is still Scrum.

- Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems.

- Scrum is simple. Try it as is and determine if its philosophy, theory, and structure help to achieve goals and create value.

- The Scrum framework is purposefully incomplete, only defining the parts required to implement Scrum theory.

- Scrum is built upon by the collective intelligence of the people using it. Rather than provide people with detailed instructions, the rules of Scrum guide their relationships and interactions.

- Scrum is founded on empiricism and lean thinking.

Key Changes:

1. Less Prescriptive, more room to explore:

Over the years, the Scrum Guide started getting a bit more prescriptive. The 2020 version aimed to bring Scrum back to being a minimally sufficient framework by removing or softening prescriptive language.

- Daily Scrum - Removed Question and Meeting after the Daily Scrum for detailed discussions, re planning, etc.

- Product Backlog Refinement -10% Capacity, estimates.

- Sprint Review - Prescriptive element.

- Sprint Retrospective - The improvements that will be implemented in the next Sprint & The detailed outcomes defined in the purpose.

- Product Backlog - How to monitor progress towards the goal.

- Removed Scrum Uses.

**Note : The above points are removed from scrum guide 2020.

2. One Team, Focused on One Product:

- The goal was to eliminate the concept of a separate team within a team that has led to “proxy” or "us and them” behavior between the PO and Dev Team.

- There is now just one Scrum Team focused on the same objective , with three different sets of accountabilities: PO, SM, and Developers.

- Roles have been replaced with accountabilities.

- Typically 10 or fewer people in the team (Previous version called the size for Development Team now Size of Scrum Team).

- Developers and not Development Team.

3. Introduction of Product Goal:

The 2020 Scrum Guide introduces the concept of a Product Goal to provide focus for the Scrum Team toward a larger valuable objective. Each Sprint should bring the product closer to the overall Product Goal.

“A product is a vehicle to deliver value. It has a clear boundary, known stakeholders, well defined users or customers. A product could be a service, a physical product, or something more abstract”.

- The Product Owner is accountable for the Product Goal and Product Backlog.

- Product Goal describes, at a high level the value of the work that the Product Owner is accountable for.

- The Product Goal is the long-term objective for the Scrum Team. They must fulfil (or abandon) one objective before taking on the next.

Details on Product Goal

- Product goals help achieve the product vision and business objectives. Goals should relate to the broader product strategy.

They should also be easy to understand, actionable, achievable, and measurable.

- Aligning goals with product vision is just the first step. As Product Owner must also align and roll product goals up to the overall business goals. This demonstrates how the product delivery will enhance success of the business.

- It also shows product stakeholders how their unique work matters. You rely on many teams for a product release, from Sales and Support to Engineering and Development. Product goals let each team know how their work contributes at a high level.

Example of Product Goal

As an example, in our demo product for Honda Cycling, our goals are the following:

- Goal: Become #1 in social fitness cycling software.

Metric: Metric:+50% market share.

- Goal: Triple revenue year over year.

Metric: Metric:+$50M revenue.

- Goal: Top rated social fitness cycling apps.

Metric: Metric:#1 rated in iOS and Android marketplaces.

- Goal: Largest partner ecosystem.

Metric: Metric:+100 partners.

Definition of Done

- A formal description of the state of the Increment when it meets the quality measures required for the product.

- The moment a Product Backlog item meets the Definition of Done, an Increment is born.

- DOD creates transparency and If DOD is not meet No Review/released returns to Product Backlog.

- Scrum Team must create a Definition of Done appropriate for the product.

- There are multiple Scrum Teams working together on a product, they must mutually define and comply with the same Definition of Done.

4. Self-Managing over Self-Organizing:

- Previous Scrum Guides referred to Development Teams as self-organizing, choosing who and how to do work.

- With more of a focus on the Scrum Team, the 2020 version emphasizes a self-managing Scrum Team, choosing who , how , and what to work on.

5. Three Sprint Planning Topics:

In addition to the Sprint Planning topics of “What” and “How”, the 2020 Scrum Guide places emphasis on a third topic, “ Why ”, referring to the Sprint Goal.

6. A Home for Sprint Goal, Definition of Done, and Product Goal:

- Previous Scrum Guides described Sprint Goal and Definition of Done without really giving them an identity. They were not quite artifacts but were somewhat attached to artifacts. With the addition of Product Goal, the 2020 version provides more clarity around this.

- Each of the three artifacts now contain ‘commitments’ to them.

- Product Backlog

- Commitment: Product Goal.

- Sprint Backlog

- Commitment: Sprint Goal.

- Increment

- Commitment: Definition of Done (now without the quotes) .

- They exist to bring transparency and focus toward the progress of each artifact.

7. Overall Simplification of Language for a Wider Audience:

- The 2020 Scrum Guide has placed an emphasis on eliminating redundant and complex statements as well as removing any remaining inference to IT work e.g. testing, system, design, requirement, etc.).

- The Scrum Guide is now less than 14 pages.

Summary

- Less prescriptive, simpler language and removal of software-specific terminology.

- Changes to some definitions, e.g., Scrum definition, empiricism, Product Backlog, Sprint Goal, Sprint Backlog, Increment, Definition of Done.

- Removed (e.g., "Scrum Uses") or reorganized content (e.g., "Measuring Progress toward Goals").

- Elements added or their relationships clarified, e.g., the "Commitments" Product Goal (new), Sprint Goal and Definition of Done.

- The concept of a Development Team within a Scrum Team was removed to reduce the potential for dysfunctions between the Product Owner and the Development Team ("us vs. them") and focus the entire Scrum Team on the same objective.

- A Scrum Team now consists of the Product Owner, Developers, and the Scrum Master. The people doing the work of creating a usable Increment are called Developers.

- The "entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint." The Developers are accountable for all aspects of creating the usable Increment.

- The terms "accountable" and "responsible" are used more consistently, and "roles" is replaced by "accountabilities".

- The Scrum Guide now uses the terms "self-managing" and "self-management" to emphasize that Scrum Teams choose "who, how and what to work on" whereas the Scrum Guide 2017 used the terms "self-organizing" and "self-organization" to describe that Development Teams chose "who and how to do work".

- The term servant leader was removed, and Scrum Masters are now described as "true leaders who serve the Scrum Team and the larger organization".

- Sprint Planning now has three topics: "Why is this Sprint valuable?", is the new first topic.

- The purpose of events is clarified and the description how to conduct them is less prescriptive.

3 Key changes for Scrum Master

1. You have to stay up-to-date - As a Scrum Master, you need to know Scrum - you are the expert after all. It means that you must take your time to read and understand the new Scrum Guide. Take notes of what changed and how it might impact your team and your organization.

2. You work with the whole organization, not just the team. Scrum Masters are true leaders who serve the Scrum Team and the larger organization.

3. You are an accountable Scrum Master. As a Scrum Master you have a few specific accountabilities to pay attention to: effectiveness and continuous improvement of the Scrum Team, relationships with stakeholders in regards to Scrum, some product activities. The Scrum Master is accountable for the Scrum Team’s effectiveness.

Download the official Scrum Guide.

Scrum is defined completely in the Scrum Guide by Ken Schwaber and Jeff Sutherland, the originators of Scrum.

Translations provided by the generous individuals and groups listed below. Please select the guide in the language you would like to download.

If you have have found a possible translation error with the Scrum Guide please contact the translator directly. If you need additional support please contact support@scrumguides.org.

Important links

Scrum Guide 2020

• https://www.scrumguides.org/download.html .

• https://www.scrumguides.org/scrum-guide.html .

Product goal

• https://www.scrum.org/resources/blog/scrum-guide-2020-update-introducing-product-goal .

Commitments

• https://www.scrum.org/resources/blog/scrum-guide-2020-update-commitments .

Self Management

• https://www.scrum.org/resources/blog/scrum-guide-2020-update-self-mgt-replaces-self-organization .

Accountabilities

• https://www.scrum.org/resources/blog/scrum-guide-2020-update-role-accountabilities .

Simplification of the Guide

https://www.scrum.org/resources/blog/scrum-guide-2020-update-what-has-been-removed .

“This extraordinary book shows a new way to simplify your life and work, increase your focus, and get more done in less time than you ever thought possible.”

—Brian Tracy, bestselling author of Eat That Frog! and Time Power

“Groundbreaking … Will upend people’s assumptions about how productive they can actually be.… Jeff Sutherland discloses to the non-tech world the elegantly simple process that programmers and web developers have been using since he invented Scrum, showing how a small, empowered, and dedicated team can deliver significantly higher quality work at a faster pace through introspection, iteration, and adaptation.”

—Michael Mangi, senior VP of interactive technology, Social@Ogilvy

“Jeff Sutherland has written the essence of Scrum for the masses. This book elevates Scrum from a fix-it tool to a way of life.”

—Hirotaka Takeuchi, professor of management practice, Harvard Business School