Normalizing agile and lean product development and aim

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
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. Page 1 of 27

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 come 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
.
• Remove what isn‘t of value to the customer or
Eliminate Waste
business partner

• Improve software development by improving the
Amplify Learning
adoption through learning

Decide As Late As Possible • Delay decisions until assumptions become fact

Deliver As Fast As Possible • Quicker delivery of results with quicker feedback

• Allow the front-line workers (i.e. development) to
Empower The Team make the major decisions about how to dvelop and
deliver the solution
• Build for perceived (customer view) and
Build Integrity In conceptual (system view) integrity, flexibility and
efficiency

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

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.

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
Individual who is ultimately accountable for the correct and
A = Accountable thorough completion of the artifact or ceremony, and the
one to whom Responsible is accountable
Individuals whose opinions are sought; and with whom
C = Consulted
there is two-way communication
Individuals who receive summary of what was "done" but
I = Informed need not be consulted and with whom there is just one-way
communication
One person may fill
Business Analyst

Project Manager
Product Owner

Scrum Master
multiple roles
Agile Coach

QA Analyst
Developer

Tester
Depicted are a
minimum set of roles,
artifacts and
ceremonies
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,


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

Copyright © 2008 Russell Pannone. All rights reserved. Page 10 of
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

27

Normalizing agile and lean product development and aim

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Normalizing agile and lean product development and aim

Ähnlich wie Normalizing agile and lean product development and aim (20)

Mehr von Russell Pannone

Mehr von Russell Pannone (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Normalizing agile and lean product development and aim