normalizing agile and lean product development and aim

This guideline by design is neither intended to be prescriptive nor complete in detail. It contains just enough

detail to facilitate a collaborative, self-directing and self-organizing, agile/lean product development team.

Copyright © 2008 Russell Pannone. All rights reserved. of 27

Normalizing Agile and Lean Product Development &

AIM

Agile and lean product development is an empirical

and adaptive approach that allows the

organization, the team and the individual to follow

a general set of values, principles and practices

– a philosophy

rather than a step-by-step process




Intent of this document

By design this set of norms is neither intended to be prescriptive nor complete in detail. It contains just enough detail to promote and facilitate a collaborative, self-directing and self-organizing agile and lean product development team. What should comes to mind is less is more. Today‘s system-software development methodologies have in common with nature the life span of infancy, childhood, adolescence, adulthood, and aging. Additionally, methodologies, sometimes as part of their life span, enter into a relationship or marriage with other methodologies; like has happened with Agile Software Development and Lean Manufacturing. Likewise, methodologies of the past and present have an associated taxonomy, new jargon and technical terminology or idiomatic expressions of the practitioner. They also tend to reuse old jargon but with different connotations. For example:

System thinking

Kanban

Kaizen

Value-stream

Velocity

Scrum

Story

Story Board

Retrospective

The what, why, and how of agile and lean product (system-software) development and delivery is not one persons vision alone; to become reality it needs to be a "shared" vision through negotiation and compromise between individuals, the team and the organization. The following is a set of norms for your agile and lean product (system-software) development teams to rally around and evolve. Look at it as musicians do sheet music. Recognizing, the more familiar the musicians are with the musical score and the more experience they have playing together, the less dependent the musicians are on the sheet music; except when introducing new musicians to the musical ensemble. This metaphor is applicable to an agile/lean product (system-software) development team and your set of norms.




We are climbing a slippery slope when setting norms. We need to be keenly aware your norms should not be rigid or prescriptive and should evolve through collaboration between self-organizing and self-directing cross-functional teams based on reality. Norm setting can only work if the team is truly able to arrive at consensus. Norms won‘t stick if members have reservations about them. However, once consensus is reached, the team is equipped with a guide that can serve to strengthen positive practices. A set of norms can serve as a common reference if contrary behaviors arise. Finally, written norms are handy for potential members and newcomers who want to quickly get a sense of the team‘s adoption of being agile. Norms in hand, a team can move forward inspired and motivated to uphold the team‘s approach and confident in the security such guidelines provide.

When you get to the Agile Implementer Matrix (AIM) some of you agile purist may cringe. AIM is primarily targeted towards those enterprises that have corporate defined roles and responsibilities; it will help reduce people‘s frustration during their agile adoption. Once the enterprise evolves from a command-and-control and specialists become generalists AIM may not be as useful.




Values

While there is value in the items on the right, we value the items on the left more.

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan




Principles .

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

2. Welcome changing requirements, even late in development. Being agile and lean harnesses change for the customer's competitive advantage.

3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

4. Business people and developers must work together daily throughout the project.

5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

7. Working software is the primary measure of progress. 8. Being agile and lean promotes sustainable development. The sponsors,

developers, and users should be able to maintain a constant pace indefinitely.

• Remove what isn‘t of value to the customer or business partner

Eliminate Waste

• Improve software development by improving the adoption through learning

Amplify Learning

• Delay decisions until assumptions become factDecide As Late As Possible

• Quicker delivery of results with quicker feedbackDeliver As Fast As Possible

• Allow the front-line workers (i.e. development) to make the major decisions about how to dvelop and deliver the solution

Empower The Team

• Build for perceived (customer view) and conceptual (system view) integrity, flexibility and efficiency

Build Integrity In

• View the software as a whole and not as a sum of its parts (System Thinking)

See The Whole




9. Continuous attention to technical excellence and good design enhances agility.

10. Simplicity--the art of maximizing the amount of work not done--is essential.

11. The best architectures, requirements, and designs emerge from self-organizing teams.

12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Scrum Framework

―There will be no Scrum Release 2.0… Why not? Because the point of Scrum is not to solve [specific problems of development]… Scrum unearths the problems caused by the complexity and lets the organization solve them, one by one, over and over again.‖1

―Scrum is a simple framework that exposes problems. It is a mirror. We are not suggesting that new ideas cannot arise and improve the framework. But attempts to ‗improve‘ it are most often (1) avoidance of dealing with the weaknesses exposed when regular Scrum is really applied, (2) conformance to status quo policies or entrenched groups, (3) belief in a new silver bullet practice or tool, (4) fuzzy understanding of Scrum and empirical process control, or (5) an attempt by the traditional consulting companies to sell you a process—―Accenture Scrum/Agile,‖ ―IBM Scrum/Agile,‖ and so on.‖2

1 Schwaber, K., 2007. “Scrum Release 2.0?” Scrum Alliance Articles, at http://www.scrumalliance.org/articles/12-scrum-release

2 Larmen, C. & Vodde, B., 2010. Practices for Scaling Lean & Agile Development, Addison Wesley




Practices A practice is a common approach for doing something with a specific purpose in mind. There are no best practices—only adequate practices in context. Since so-called best practices are ‗best,‘ they also inhibit a ―challenge everything‖ culture and continuous improvement—a pillar of lean thinking. Why would people challenge ‗best‘? Mary Poppendieck, coauthor of Lean Software Development, reiterates this point and draws the historical connection from best practices to Taylorism:

Frederick Winslow Taylor wrote ―The Principles of Scientific Management‖ in 1911. In it, he proposed that manufacturing should be broken down into very small steps, and then industrial engineers should determine the ‗one best way‘ to do each step. This ushered in the era of mass production, with ‗experts‘ telling workers the ‗one best way‘ to do their jobs. The Toyota Production System is founded on the principles of the Scientific Method, instead of Scientific Management. The idea is that no matter how good a process is, it can always be improved, and that the workers doing the job are the best people to figure out how to do it better… Moreover, even where a practice does apply, it can and should always be improved upon. There are certainly underlying principles that do not change. These principles will develop into different practices in different domains...‖3

3 Poppendieck, M., 2004. “An Introduction to Lean Software Development,” at www.poppendieck.com/pdfs/Interview.pdf




Agile Implementer Matrix (AIM) The Agile Implementer Matrix (AIM) may make some of you agile purist cringe. AIM is primarily targeted towards those enterprises that have corporate defined roles and responsibilities; it will help reduce people‘s frustration during their agile adoption. Once the enterprise evolves from a command-and-control and specialists become generalists AIM may not be as useful.

AIM (Agile Implementer Matrix)

R = Responsible Defines and commits to getting "done", done

A = Accountable Individual who is ultimately accountable for the correct and thorough completion of the artifact or ceremony, and the one to whom Responsible is accountable

C = Consulted Individuals whose opinions are sought; and with whom there is two-way communication

I = Informed Individuals who receive summary of what was "done" but need not be consulted and with whom there is just one-way communication

One person may fill multiple roles Depicted are a minimum set of roles, artifacts and ceremonies

Ag

ile C

oa

ch

Bu

sin

ess A

naly

st

De

velo

pe

r

Pro

du

ct O

wn

er

Pro

ject M

ana

ge

r

QA

An

aly

st

Scru

m M

aste

r

Teste

r

Artifacts

Burndown Charts C C C I I C R/A C

Product Backlog C C C R/A I I I I

Product Roadmap I C I R/A I I I I

Release Plan I C C A C C R C

Sprint Backlog C C C I I C R/A C

Story C R R A/C I C C C

Test Script C C C I I C I R/A

Vision I C I R/A I I I I

Ceremonies

Daily Scrum C R R I I R A R

Release Planning I C C A C C R C

Sprint Planning C R R I I R A R

Sprint Retrospective C R R I I R A R

Sprint Review C R R C I R A R




Roles

Have you recently joined an Agile team, or have been part of one for some time, and aren't fully clear on the roles and responsibilities - especially yours? The collaborative nature of Agile presents a interesting paradigm shift where roles and responsibilities somewhat blur and teams ideally self-organize.

Therefore, as you, your team and your organization evolve and adapt to being agile and lean and using the Scrum framework it is about each existing role complementing each other's responsibilities working towards the delivering of an increment of the product while the individual, team and organization work through the redefinition of organizational roles and responsibilities in your new world of being agile and applying the Scrum framework. Team members should reflect and refine their roles to meet the goal and needs of the team.

Agile Coach

Agile coaches attempt to influence teams in different ways. Based on empirical knowledge agile coaches typically work by instinct and intuition. This makes it very hard to explain what coaches do and a challenge to teach people how to coach agile teams.

First and foremost an agile coach must be a ―servant leader‖. Robert Greenleaf, who after a career working with many talented leaders at AT&T from the mid-1920s to the mid-1960s, identified the desire to serve as the core motivation for great leaders, and the growth of people as the chief indicator of such leaders, whom he called ―servant leaders‖. ―The best test (of the servant leader) is, do those served grow as persons? Do they become healthier, wiser, freer, more autonomous (self-directed and self-organizing), more likely themselves to become servant leaders.‖

Next an agile coach must be both a system-thinker [see the big picture] and a tactical-thinker.

System thinking is the process of predicting, on the basis of anything at all, how something influences another thing. It has been defined as an approach to problem solving, by viewing "problems" as parts of an overall system, rather than reacting to present outcomes or events and potentially contributing to further development of the undesired issue or problem. System thinking, planning, and actions reflect one‘s ability to take into account the big picture, to recognize patterns and trends, mental models, foresee issues, predict outcomes, and have smart "Plan B's" to fall back on. System thinking deals with mission and purpose - why your business exists, how it makes a difference, and where it will be in the future.

Tactical thinking refers to the hands-on part of getting the job done; making sure the system-thinking vision is met. Getting the job done, with respect to ―being‖ agile,



Copyright © 2008 Russell Pannone. All rights reserved. of

27

consists of iterative and incremental product development and delivery, with progress measured by the commercial or operational value added incrementally.

When a team is working towards ―being‖ agile, the agile coach introduces a set of practices around which the team self-organizes & self-directs. The team in turn selects one or more practice to apply to an iteration/sprint. The agile coach must have hands-on experience applying the practices. Return to Top

Business Analyst

The Business Analyst becomes a valuable contributor to the Product Owner.

The Business Analyst is a role that seems neglected by Scrum. To ensure close collaboration between the team and the Product Owner, Scrum ensures that the necessary elements are effectively communicated directly to the team without complex documentation. However, to ensure continuity of information, we know that functional documentation that is adequate and representative of the system-software to be developed is essential.

In a multi-team context, the Business Analyst may be called upon to play the role of Product Owner. He/she then becomes responsible for core components of the product within the various sub-teams. Return to Top

Developer A Developer, iteratively and incrementally, turns Product Backlog items (stories) into potentially shippable functionality every Sprint.

Developers may be cross-functional

Developers often have specialized skills, such as programming, architecture, user interface design, database design, etc.

Return to Top

Product Owner The Product Owner represents the single, unified view of the product and is ultimately accountable for its delivery and the evaluation if it meets its targeted ROI. The Product




27

Owner works with various stakeholders to define what is important to have in the product and the prioritization of these features. Return to Top

Project Manager Traditionally, the project manager is responsible for determining who, what, and when activities need to be performed and then to ensure the team complies with the plan that was prepared to meet the budget, time and scope constraints. With the traditional approach, project management is based on compliance with the plan while Agile/Lean and Scrum propose a different approach where maximizing the business value is the main vector of project management. Under this new approach, the project manager needs to collaborate with the team and delegate to them some of his/her traditional responsibilities since the team will determine who does what, how, and when within the constraints of the project; as part of sprint planning.. In this context, the role of the Scrum Master is to enforce the framework and seeks to build an efficient self-organized team. To the question ―Do we still need a project manager in Agile?‖, experience shows us that in most organizations, the answer is yes. The need for accountability, regulatory compliance and alignment with the framework and IT governance are not covered by the role of the Scrum Master and as such remain the responsibility of the project manager. However, the project manager needs to adapt their management style and use leadership rather than authority with the team to get things done. In the context of a multi-team organizational structure, the presence of a project manager is also valuable, where he/she is coordinating the teams and the synchrony between them and between entities external to the project teams. Based on empirical knowledge, some project managers are more willing to become Product Owners while others will feel challenged by the role of Scrum Master. Return to Top

QA Analyst Rather than building the product (system-software) in a linear fashion and resolving bugs at the end of the system-software development lifecycle, agile and lean product development teams address defects as soon as they‘re discovered. Such conscientious




27

coding might add work in the short-term, but it ensures that the team is always working with clean, functional code and vigilantly eliminating bugs, which significantly cuts development time, eliminates waste and delivers value frequently. Quality is a fundamental concern in agile and lean product development as we iteratively and incrementally develop value adding, quality system-software. Part of the reason for success being agile and lean and applying the Scrum framework is not to offend or alienate folks in exiting organizational roles such as Quality Analyst, Project Managers, Business Analysts, Testers, etc.; roles not specifically defined in Scrum. When a quality analyst position exists in your organization this role should be an active member of the Scrum team and right from the start of the project. A QA analyst assigned to a Scrum team has the following responsibilities:

Participates in planning sessions to raise issues relating to quality

Helps clarify the definition of ―Done‖‗

Prepares plans for acceptance testing

Verifies and validates the increments of product delivered

Continuous adaptive and empirical process improvement Minimum skills

General knowledge of all aspects of agile and lean product development

Experience in a wide variety of testing efforts, techniques and tools

People skills, especially diplomacy and advocacy skills

Planning and management skills

Knowledge of the domain, system or application-under-test

Experience programming or managing programming teams Return to Top

Scrum Master The Scrum Master is responsible for ensuring that the Scrum Team adheres to Scrum values, practices, and rules. The Scrum Master helps the Scrum Team and the organization adopt Scrum. The Scrum Master teaches the Scrum Team by coaching and by leading it to be more productive and produce higher quality products. The Scrum Master helps the Scrum Team understand and use self-management and cross-functionality. However, the Scrum Master does not manage the Scrum Team; the Scrum Team is self-organizing and self-directing.




27

Return to Top

Tester A Tester is first a team member that executes test cases for story verification and validation. The tester may be done by any team member. For example, the developer can test their code with unit tests, component integration tests, or automated system tests. The idea here is that the tester role is a mindset that different team members can assume when needed. Now that being said if you have an individual whose sole purpose is to be the tester on the team then they should focus on testing methodologies and how the testing can be done. They are also responsible for ensuring that the testing is being done in the most agile/lean way. They should be suggesting testing approaches during planning and estimation meetings. An agile tester guides the entire product development team in a way that ensures that features of the product and the product as a whole behave as intended and without bugs. An important step is communicating how we know when a story/feature is done. We do this by fleshing out enough test cases and test scripts, from acceptance criteria; so that each story/feature can be verified and validated for functional completeness as it's developed. As testers, we are also responsible for ensuring that non-functional requirements (performance, scalability, security, usability, and etc.) are also met. A Tester has the following responsibilities

Focus on testing methodologies and how the testing will can be done

Ensure that the testing is being done in the most agile/lean way

Participates in planning sessions suggesting testing

Guides the entire product development team in a way that ensures that features of the product and the product as a whole behave as intended and without bugs

Helps clarify the definition of ―Done‖

Derives test cases and test scripts, from acceptance criteria; so that each story/feature can be verified and validated for functional completeness as it's developed

Ensuring that non-functional requirement (performance, scalability, security, usability, and etc.) are also met

Gathering and managing the Test Data

Logging outcomes and verifying that the tests have been run

Analyzing and guiding the recovery from execution errors

Communicating test results to the team Minimum skills

Good analytical skills




27

A challenging and inquiring mind

Attention to detail and tenacity

Understanding of common software failures and faults

Knowledge of the domain

Knowledge of the system or application-under-test

Experience in a variety of testing efforts

Training in the appropriate use of test automation tools

Experience using test automation tools

Programming skills

Debugging and diagnostic skills

Return to Top

Artifacts

Burndown Charts Sprint Burndown Chart

The Sprint Burndown Chart is a graph of the amount of Sprint Backlog work remaining in a Sprint cross time in the Sprint. To create this graph, determine how much work




27

remains by summing the backlog estimates every day of the Sprint. The amount of work remaining for a Sprint is the sum of the work remaining for all of Sprint Backlog. Keep track of these sums by day and use them to create a graph that shows the work remaining over time. By drawing a line through the points on the graph, the Team can manage its progress in completing a Sprint‘s work. Duration is not considered in Scrum. Work remaining and date are the only variables of interest. Product Burndown Chart

The Product Backlog Burndown Chart records the sum of remaining Product Backlog estimated effort across time. The estimated effort is in whatever unit of work the Scrum Team and organization have decided upon. The units of time are usually Sprints. Return to Top




27

Product Backlog

The requirements for the product that the Team(s) is developing are listed in the Product Backlog as stories. The Product Owner is accountable for the Product Backlog, its contents, its availability, and its prioritization. The Product Backlog is never complete. The initial cut at developing it only lays out the initially known and best-understood requirements. The Product Backlog evolves as the product and the environment in which it will be used evolves. The Product Backlog is dynamic in that it constantly changes to identify what the product needs to be appropriate, competitive, and useful. As long as a product exists, the Product Backlog also exists. The Product Backlog represents everything necessary to develop and launch a successful product. Product Backlog items have the attributes of a description, priority, and estimate. Priority is driven by risk, value, and necessity. There are many techniques for assessing these attributes. The Product Backlog is sorted in order of priority. Top priority Product Backlog items drive immediate development activities. The higher the priority, the more urgent it is, the more it has been thought about, and the more consensus there is regarding its value. Higher priority backlog items are clearer and have more detailed information than lower




27

priority backlog items. Better estimates are made based on the greater clarity and increased detail; the lower the priority, the less the detail.

Attributes

Product Backlog Owner Name

Program and Project Identifier

Baseline Signoff Date

Story

Text

Acceptance Criteria

Priority

Size

State

o Open - the story not yet assigned to a Release or Sprint

o Refining – not clear about the desired behavior and functionality the

system-software must implement

o Assigned to Release - the story has been assigned to a Release

o Assigned to Sprint - the story has been assigned to a Sprint

o Assigned to Team Member - the story has been assigned to a team

member

o In-Progress - the team member responsible for the story is actively

working on developing and implementing the story

o Done - the development and implementation of the story has been

verified and validated based on the agreed upon definition of done

o Released - part of system-software components now running in

production

o Deleted – no longer required

When to baseline

1. After each Release Planning session

2. After each Sprint Planning session

Return to Top




27

Product Roadmap

―If you don't know where you are going, that's where you'll end up.‖ -Yogi Berra

If you don't know where you are going, it's impossible to determine the best way to get there. A Product Roadmap is essential for product planning and development. Product roadmaps outline when products are scheduled for release and include an overview of their primary and secondary features.

Just like a journey is planned upfront and shared with the fellow travelers, a product roadmap is created and communicated to the development team. The goals for doing so are for the product owner to:

Communicate the whole

Determine and communicate when releases are needed

Determine what functionality is sufficient for each release

Focus on business value derived from the releases

The delivery team on the other hand will:

See the whole




27

Learn about the steps to realize the vision

Learn the business priorities

Provide technical input to the roadmap

Provide estimates for the projected features

Return to Top

Release Plan

“If you don't know where you are going, that's where you'll end up.” - Yogi Berra

Release Planning is an integral part of Agile and Lean Product Development.

A product roadmap is essential for product planning and development.

Product roadmaps outline when products are scheduled for release and include an overview of their primary and secondary features.

The Release Plan is comprised of: 1. The release theme

2. The release content

3. Business value statement for the release

4. The release timeline




27

Return to Top




27

Sprint Backlog

The Sprint Backlog consists of the story and associated tasks the Team performs to turn Product Backlog items into a ―done‖ increment of the product. It represents all of the work that the Team identifies as necessary to meet the Sprint goal and to deliver the stories that they commit to getting done in the Sprint. Return to Top




27

Story

Figure 1.0 – A story and related acceptance criteria

Stories are vital to the Product Backlog, Release Planning and Sprint Planning and delivering something of commercial or operational value iteratively and incrementally. The more experience you have with writing stories, and estimating story size using a relative unit of measure, the easier it will become for you to recognize when a story is at the right level of detail. When you are sizing your stories, at the Product Backlog level, a story should contain just enough detail for the team to be able to estimate its relative size to other stories. When estimating your stories, at the Sprint Backlog level, a story should contain enough detail for the team to be able to determine what the solution involves or what it will take them to deliver the story. A good story is negotiable. It is not an explicit contract for features or functionality; rather stories are short descriptions of functionality, the details of which are to be refined in a conversation between the Product Owner (aka, the business or customer) and the development team. The challenge comes in learning to include just enough detail. At the time the story is written some important details may become known, they should be included as acceptance criteria for the story, as shown in Figure 1.0.

Return to Top




27

Test Script Test Scripts are the steps or instructions that a tester uses to walk through a test. Test scripts serve as a set of instructions, derived from test cases and acceptance criteria, to be followed by the tester. The execution of the test script is performed on the system-software to verify and validate the system-software functions as expected. Test scripts can be automated or manual. Return to Top

Vision

What

Summary of the major benefits and features the product will provide

Gives context to the reader

Defines the business context for the product. In which domain is it going to function (for

example, telecom or bank) and what market—who are the users? State whether the

product is being developed to fulfill a contract or if it is a commercial product.




27

Who (Stakeholders) There are a number of stakeholders with an interest in the development and not all of

them are end users. Think of this as outside-in-design.

Customer/Consumer Other vested interests

Provides the background and justification for why the requirements are needed

Why

Need and opportunity

When

Begins the process of project scheduling by illuminating the stakeholders‘ time expectations regarding the product. Also helps you dig into their expectations by defining the circumstances in which the new product would be used.

Constraints & Assumptions

Express the constraints under which the project is undertaken. These constraints impact risk and

cost. They could be things like external interfaces that the product must adhere to, standards,

certifications or a technical approach employed for strategic reasons, such as using a certain

database technology or distribution mechanisms.

Return to Top




27

Ceremonies

Daily Scrum Each Team meets daily for a 15-minute meeting called the Daily Scrum. The Daily Scrum is at the same time and same place throughout the Sprints. During the meeting, each Team member answers the following 3 questions:

1. What he or she has accomplished since the last daily scrum? 2. What he or she is going to do before the next daily scrum? 3. What obstacles are in his or her way?

Daily Scrums improve communications, eliminate other meetings, identify and remove impediments to development, highlight and promote quick decision-making, and improve everyone‘s level of project knowledge. The Scrum Master ensures that the Team has the meeting. The Team is responsible for conducting the Daily Scrum. The Scrum Master teaches the Team to keep the Daily Scrum short by enforcing the rules and making sure that people speak briefly. The Daily Scrum is not a status meeting. It is not for anyone but the people transforming the Product Backlog items into an increment of the product that the Team has committed to getting done during the Sprint. The Daily Scrum serves as a feedback loop to get better at what the team is doing. Return to Top

Release Planning Release planning answers the questions:

1. How can we turn the vision into a winning product in the best possible way? 2. How can we meet or exceed the desired customer satisfaction and Return on

Investment? The release plan establishes the goal of the release, the highest priority Product Backlog items, the major risks, and the overall features and functionality that the release will contain. It also establishes a probable delivery date and cost that should hold if nothing changes. The organization can then inspect progress and make changes to this release plan on a Sprint-by-Sprint basis. Products are built iteratively and incrementally using Scrum, wherein each Sprint creates an increment of the product, starting with the most valuable and riskiest. More and more Sprints create additional increments of the product. Each increment is a




27

potentially shippable slice of the entire product. When enough increments have been created for the Product to be of value, the product is released.

Return to Top

Sprint Planning Sprint Planning is when the sprint/iteration is planned. It is time-boxed to eight hours for a one month Sprint. For shorter Sprints, allocate approximately 5% of the total Sprint length to this meeting and consists of two parts. The first part is when what will be done in the Sprint is decided upon. The second part is when the Team figures out how it is going to build this functionality into a product increment during the Sprint. There are two parts to the Sprint Planning Meeting: the ―What?‖ part and the ―How?‖ part. Some Scrum Teams combine the two. In the first part, the Scrum Team addresses the question of ―What?‖ Here, the Product Owner presents the top priority Product Backlog to the Team. They work together to figure out what functionality is to be developed during the next Sprint. The input to this meeting is the Product Backlog, the latest increment of product, the capacity of the Team, and past performance of the Team. The amount of backlog the Team selects is solely up to the Team. Only the Team can assess what it can accomplish over the upcoming Sprint and make a commitment to getting it done.

Return to Top

Sprint Retrospective After the Sprint Review and prior to the next Sprint Planning meeting, the Scrum Team has a Sprint Retrospective meeting. At this 2 hour time-boxed meeting the Scrum Master encourages the Scrum Team to revise, within the Scrum framework and practices, their development process to make it more effective and enjoyable for the next Sprint. The purpose of the Retrospective is to inspect how the last Sprint went in regards to people, relationships, process and tools. The inspection should identify and prioritize the major items that went well and those items that-if done differently-could make things even better. These include Scrum Team composition, meeting arrangements, tools, definition of ―done,‖ methods of communication, and processes for turning Product Backlog items into something ―done‖ which is commercial or operational valuable. By the end of the Sprint Retrospective, the Scrum Team should have identified actionable improvement measures that it implements in the next Sprint.




27

Return to Top

Sprint Review At the end of the Sprint, a Sprint Review meeting is held. This is a four hour time-boxed meeting for one month Sprints. For Sprints of lesser duration, this meeting must not consume more than 5% of the total Sprint. During the Sprint Review, the Scrum Team and stakeholders collaborate about what was just done. Based on that and changes to the Product Backlog during the Sprint, they collaborate about what are the next things that could be done. This is an informal meeting, with the presentation of the functionality intended to foster collaboration about what to do next. The meeting includes at least the following elements.

• The Team demonstrates the stories is has completed and answers questions • The Product Owner then discusses the Product Backlog as it stands • The entire group then collaborates about what it has seen and what this means

regarding what to do next • The Sprint Review provides valuable input to subsequent Sprint Planning

meeting

Return to Top

normalizing agile and lean product development and aim

Technology