Agile Tooling
Agile
Tooling refers to hi-tech or low-tech software or artifacts designed to
increase the sense of team and to encourage participation among the members.
Examples include version control software, collaboration software, or video
conferencing for distributed teams.
wireframe
A wireframe
is a "low fidelity” prototype. This non-graphical artifact shows the
skeleton of a screen, representing its structure and basic layout. It contains
and localizes contents, features, navigation tools and interactions available
to the user. It is often used as a communication tool serving as an element of
conversation and confirmation of Agile user stories.
Domain Model
Domain Model
illustrates: the business
structure, its entities, and their relationships.
supply system
A supply
system where items are produced at the request of the customer is called a Pull System.
Ethnocentrism
An attitude
that one's group is
superior to others is called an Ethnocentrism.
Grooming
Grooming is
an ongoing collaborative effort led by the Product Owner and including
significant participation from internal and external stakeholders as well as
the Scrum Master and development Team.
Decision framing
Decision framing focuses on who gets involved in the decision
process. Managers who make decisions without input from subordinates and peers
make poor decisions. Engineers who make decisions without input from managers
and peers make poor decisions. Who makes the decision is less important than
getting the right people involved in the decision process.
Relative Weighting
An approach
that is similar to Kano’s in that considers both the positive benefit of the
presence of a feature and the negative impact of its absence is Relative Weighting
approach.
Ishikawa or fishbone diagrams or Cause-and-effect
Cause-and-effect
diagrams - also called Ishikawa or fishbone diagrams - show the relationship between the effects of problems
and their causes. Kauru Ishikawa developed cause-and-effect diagrams.Ishikawa
diagrams show the steps
needed to identify the risk
Morale Barometer Metric
A metric for
the health of Team
dynamics is called Morale Barometer.
Mind map
A mind map
is a technique is used to create a graphical diagram to represent words, ideas, tasks, or other
items linked to and arranged around a central key word or idea
A mind map is a
graphical technique of taking notes and visualizing thoughts using a radiant
structure.
Story mapping
Story
mapping is a technique popularized by Jeff Putton that takes a user-centric
perspective for generating a set of user stories. The basic idea is to
decompose high-level user activity into a workflow that can be further
decomposed into a set of detail
Expert Judgment
Expert
Judgment does not need seeking consensus as it is not a collaborative effort.
The Delphi technique
The
Delphi technique is a
commonly used tool to secure expert
judgment while initiating a project. Peer review is a project selection tool, Expected value is a method quantitative risk analysis, and 'WBS' is a project-planning tool.
judgment while initiating a project. Peer review is a project selection tool, Expected value is a method quantitative risk analysis, and 'WBS' is a project-planning tool.
Expert
opinion
approach is less useful
on agile projects than on traditional projects. On an agile project, estimates
are assigned to user stories or other user-valued functionality. Developing
this functionality is likely to require a variety of skills normally performed
by more than one person. This makes it difficult to find suitable experts who
can assess the effort across all disciplines. On a traditional project for
which estimates are associated with tasks this is not as significant of a
problem because each task is likely performed by one person.
Parkinson’s Law
Parkinson’s
Law states "Work expands so as to fill the time available for its
completion." In Agile processes, we use the notion of a
"timebox" or "spike" to deal with this sort of work.
Pareto Diagram
A Pareto
Diagram is a specific kind of histogram, ordered by frequency of occurrence.
Crystal methodologies
Alistair Cockburn
indexes the Crystal methodologies by color: Clear, Yellow, Orange, Red,
Magenta, Blue, Violet, and so on. The other restriction on Crystal
methodologies is that they address only colocated teams. As discussed earlier,
none of the distributed and offshore development projects would count as
methodologically successful. The only recommendation I have for such projects
is to put the team together at one location. Two values are that Crystal
methodologies are intrinsically People- and communication-centric and Highly
tolerant.
parking lot
A "parking
lot" diagram provides the development team, the customer team, and
management with a useful overview of value and scope status. Whereas the
typical Gantt charts emphasize schedule and tasks, a parking lot diagram
emphasizes capability and story progress first and foremost.
Value Stream Maps
Value Stream Maps exist
for two purposes: to help organizations identify and end wasteful activities.
Finding problems and creating a more efficient process isn't easy; even the
best organization can be made more efficient and effective. But bringing about
substantive organizational change that actually eliminates waste is a tall
order.
As for the value stream map itself, it
is actually a form of a flowchart.
Delphi technique
The Delphi
technique is a facilitated process to reach a consensus of experts using
questions and feedback. Only the facilitator is aware of who is participating.
It is a technique to reduce bias and prevent any one person from exerting under
influence
Root-cause analysis
You can use
root-cause analysis any time you notice a problem—when you find a bug, when you
notice a mistake, as you’re navigating, and in retrospectives. It needs a few
seconds. Keep your brain turned on and use root-cause analysis all the time.
|
Root cause analysis looks beyond the symptoms to get to the core issue
that is causing the problem. One way this is accomplished is through Cause
and Effect Diagram. It is also known as Ishikawa Diagram.
|
Virginia Satir’s
Change
models like Virginia Satir’s show that once you start a change initiative, a
drop in productivity is highly probable due to the period of resistance and
chaos. Your objective is to shorten this phase by completing all your
preparation efforts before the transition starts, not during the transition.
Documents
Documents support
communication and collaboration, enhance knowledge transfer, preserve
historical information, assist ongoing product enhancement, and fulfill regulatory
and legal requirements. They are not unimportant, just less important than
working versions of the product.
Affinity estimating
Affinity estimating
provides a way to rapidly estimate your backlog.
Spider Web
All products and
services coexist within a larger context of an ecosystem of related,
complementary, and even competitive products and services. Unfortunately,
product designers often fail to recognize and leverage the relationships within
this ecosystem. This often means they miss innovative opportunities to create
happier customers and capture more revenue. The Spider Web game helps you
understand how your customer sees the relationships between your product and
service and other products and services. You can then use this information to
capture more revenue by creating innovations around these relationships. This
is a description of the Spider Web innovation game.
planned
The project is planned
as normal for delivery of the entire set of functionality; however, some amount
of the work is optional and will only be included if time permits. The optional
work is developed last, only after the mandatory work is complete.
Analysis Task
A task that provides
insight on requirements, which in turn leads to other tasks is called Analysis
Task.
Padding
Arbitrarily added time to an estimate
Exploratory testing
Testing is
used to look for surprises
and gaps in the software and provides an after-the-fact check on the
team's practices
Rolling Wave Planning
Rolling Wave Planning
indicates a technique used to plan in stages instead of doing so early in the
project.
Theory X,Y
In Theory X, employees are
assumed to be lazy and
shiftless and will avoid work and responsibility if they can. Theory Y proposes that people
want to do well and are self-motivated
to succeed if given the opportunity. Theory Y is far removed from Frederick Taylor's early work in
which he asserted that extrinsic motivators (rewards and punishments) were
required to extract any effort beyond the minimum allowed for continued
employment
Context-free questions
Context-free questions do not imply an answer
("When did you stop beating your wife?") so the respondent does not
feel a need to give the "right" answer. Open-ended questions allow
detailed responses that go beyond a simple yes or no. Open-ended, context-free questions are best
because they do not influence the response and they allow a broader range of
responses than yes or no.
Kaizen
Kaizen is
strongly aligned with Agile in the way it encourages changes from the workers
rather than asking management what should be changed. Therefore, it's strongly
aligned with Retrospective Meeting in Scrum.
Sashimi
Similar to
the way every other slice tastes. Scrum uses the sashimi technique to require
that every slice of functionality created by the developers be complete.
Metaphor
The Scrum
Master is a facilitator, coach, mentor and bulldozer! A Scrum Master is often
compared to a sheepdog, responsible for keeping the flock together and the
wolves away. Chicken refers to those outside the three Scrum roles.
CRACK
An effective
product owner is Committed, Responsible, Authorized, Collaborative, and
Knowledgeable(CRACK)
Risk Map
One of the
best ways to visually display risks in a succinct manner is to use a Risk Map.
On the vertical axis you have the probably of a given risk occurring, that is,
the likelihood that the risk will materialize and become an Issue. On the
horizontal axis we have the impact that the risk will have on the project or
program should it materialize..
Feature card
A feature
card starts a requirements conversation. An FSP tries to cover all requirements
immediately. A feature card is used to record conversations. An FSP doesn't
include conversations but focuses on documenting how a documented business
requirement will be met. A feature card focuses on verbal communication, common
understanding, and synchronizing the team on the customer goals. An FSP focuses
on documenting the functional details and having team members read the FSP to
understand what they should do.
Estimates
are not created by a single individual on the team. Agile teams do not rely on
a single expert to estimate. Despite well-known evidence that estimates
prepared by those who will do the work are better than estimates prepared by
anyone else, estimates are best derived collaboratively by the team, which
includes those who will do the work.
Force field analysis
Force field analysis is
a management technique developed by Kurt Lewin, a pioneer in the field of
social sciences, for diagnosing situations. Lewin assumes that in any situation
there are both driving and restraining forces that influence any change that
may occur.
Gardeners prune trees
Gardeners prune trees
to control their growth. Sometimes the pruning is artistic, and we end up with
shrubs shaped like animals or interesting abstract shapes. Much of the time the
pruning is designed to build a balanced tree that yields high-quality fruit.
The process isn't about "cutting," it is about "shaping."
Use this metaphor to help create the product your customers desire.
Hardening iteration
Many agile teams will
set aside an iteration at the end of the project to use for
"hardening" (preparation for final rollout of the product). Note that
this is not a bug-fixing iteration! For an internal release, this hardening
iteration may consist of a variety of production-readiness activities, whereas
for an external release, additional tasks such as capturing final screenshots
for promotional materials and lining up production facilities might be items to
consider.
Inter-team Commitment Story
As project size
increases we need similar mechanisms to allow feature teams to work together
with minimal management involvement. This mechanism is the Inter-team
Commitment Story, a brief written agreement between feature teams.
Ideal Time
On a software project,
ideal time differs from elapsed time not because of timeouts, incomplete
passes, and injuries but because of the natural overhead we experience every
day. On any given day, in addition to working on the planned activities of a
project, a team member may spend time answering email, making a support call to
a vendor, interviewing a candidate for the open analyst position, and in two
meetings.
Osmotic communication
When osmotic
communication is in place, questions and answers flow naturally and with
surprisingly little disturbance among the team.
Healthy coaching
1. The Magician,
2. The Wise Fool, and
3. The Dreamer
Situational Leadership.
A technique where a
manager adjusts personal interactions and approach to the team according to the
current team dynamic is called a Situational Leadership.
Requirement
The results of the
requirements specification process, whatever the engineering discipline
involved, should be documented as a hierarchy such as product, platform, group,
and component. For business software applications, these categories could be
application, business area, capability, feature, and story. Small software
products might use only the story level, whereas large industrial products may
use the entire hierarchy.
Application Lifecycle Management.
Focused and involved
management of the entire software development process, end to end is called a
Application Lifecycle Management.
Technique commonly Automate Build
A technique
commonly used in the context of crafting automated unit tests and automated
builds. It consists of instantiating a test-specific version of a software
component (typically a class), which instead of the normal behaviors provides
precomputed results, and often also checks that it’s invoked as expected by the
objects being tested. For instance, the "mock" version of a database
component will a) provide "canned" answers to database queries,
instead of connecting to a real live database, and b) verify that the database
is being accessed in the manner expected and stipulated in the test.
Fractional assignment
Some
organizations like to assign
people to multiple projects simultaneously.
Stakeholder analysis
One of the
activities that helps is a process known as stakeholder analysis. When
performing stakeholder analysis, the stakeholders are identified, and their
interest in the project is understood. All of this information is captured in a
stakeholder register, which is a simple artifact.
Complexity factors
complexity factors include team size, team distribution,
mission criticality, and domain knowledge gaps, whereas uncertainty
factors include market uncertainty, technical uncertainty, and project
duration.
Just In Time
Just In Time is a an
inventory management process that lets a company have little or no excess
inventory in stock, other than what they need to build existing order.
Multitasking
Multitasking exacts a
horrible toll on productivity. Clark and Wheelwright (1993) studied the effects
of multitasking and found that the time an individual spends on value adding
work drops rapidly when the individual is working on more than two tasks.
Factor of reducing turnover risk in Agile project
The impact
of turnover can be reduced by cross training (which rarely happens) and
documentation (which coveys very little of the tacit knowledge that is so critical
to success). Agile projects have built-in turnover mitigation because of the
emphasis on collaboration. In software development, for example, the use of
pair programming has demonstrated better knowledge sharing within the team,
which reduces the impact of turnover. Employee morale generally improves in an
agile environment because of the emphasis on self-organization and the
excitement of frequent iteration delivery of working products.
Extrinsic and intrinsic quality
Customer quality (which is
extrinsic or external) delivers value in the short term. Technical quality (which is intrinsic or
internal) enables continuous delivery of value over time. Poor quality
work results in unreliable products, but more critically, it results in
products that are far less responsive to future customer needs.
Soft Skills
It's a set
of skills that influence how we interact with each other. It includes such
abilities as effective
communication, creativity, analytical thinking, diplomacy, flexibility,
change-readiness, and problem solving, leadership, team building, and listening
skills
Schedule Based Planning
Is a release planning
method that focuses on time rather than features or scope.The place where work
is actively being done is sometimes called Gemba.
FDD
FDD prefers individual
code ownership and seeks to avoid refactoring by focusing on domain modeling.
FDD is also scalable and works with multiple teams or large teams. Scrum and XP
prefer shared code ownership. TDD is not an Agile methodology, but an
engineering technique in XP.
Analogous Estimation.
An estimation technique
which compares a project's scope with those of previous projects is called
Analogous Estimation.
Scope creep
Scope creep is also
referred to as "requirements inflation," and the longer the delivery
cycle the more likely additional requirements or changes to existing
requirements will occur.
Timboxing and WIP
Timboxing is a
technique of lmiting the amount of WIP. WIP represents an inventory of work
that is started but not yet finished. Failing to properly manage if can have
serious economic consequences. Because the team will plan to work on only those
items it believes it can start and finish withn the sprint, timeboxing
establishes a WIP limit each sprint.
feature breakdown structure (FBS)
During
detailed planning, agile development favors a feature breakdown structure (FBS)
approach instead of the work breakdown structure (WBS) used in waterfall
development approaches
Advantage
· They allow
communication between the customer and the development team in terms both
can understand.
can understand.
· They allow the
customer to prioritize the team's work based on business value.
· They allow
tracking of work against the actual business value produced.
Stories and Use cases
One of the
most obvious differences between stories and use cases is their scope. Both are
sized to deliver business value, but stories are kept smaller in scope because
we place constraints on their size (such as no more than ten days of
development work) so that they may be used in scheduling work. A use case
almost always covers a much larger scope than a story.
User stories or other items that are likely to be more
distant than a few iterations can be left as epics or themes. That's why they
are primaly located at the bottom.
Epic is
often called Capability.
Where the user stories of a release plan are estimated
in story points or ideal days, the tasks on the iteration plan are estimated in
ideal hours.
Advantages of user stories
Some of the
advantages of user stories over alternative approaches are: User stories
emphasize verbal communication, User stories are comprehensible by everyone,
User stories are the right size for planning, User stories work for iterative
development, User stories encourage deferring detail, User stories support
opportunistic design, User stories encourage participatory design, User stories
build up tacit knowledge.
User stories originated
as part of Extreme Programming. Naturally, stories fit perfectly with the other
practices of Extreme Programming. However, stories also work well as the
requirements approach for other processes.
User stories may and
should be supplemented with whatever other written information helps provide
clarity against what is desired.
User stories that will
be worked on in the near future (the next few iterations) need to be small
enough that they can be completed in a single iteration. These items should be
estimated within one order of magnitude
When a story (possibly
an epic) is disaggregated into its constituent stories, the sum of the
estimates for the individual stories does not need to equal the estimate of the
initial story or epic.
The front of a story
card contains the story and notes about open questions while the back of the
card contains details about the story in the form of tests that will prove
whether or not it works as expected.
Theme
A set of
related user stories may be combined together (usually by a paper clip if
working with note cards) and treated as a single entity for either estimating
or release planning. Such a set of user stories is referred to as a theme.
Scrum
User
Stories, Features, Use Cases can be successfully used in Scrum, but it's not
required. This question refers to the best practices and core of the Scrum
that can be found in the Scrum Guide
Innovation Games or Games of collaborative play
Innovation
Games possess several qualities that stand out among the various approaches.
One quality is reflected in their name: Innovation Games. You can refer to them
as "games of collaborative play," This can be contrasted with
traditional surveys and focus groups, which are often not designed to be fun
and may not include a heavy emphasis on collaboration
Iterative development
Iterative
development acknowledges that we will probably get things wrong before we get
them right and that we will do things poorly before we do them well. As such,
iterative development is a planned rework strategy.
Iterations
Iterations
are timeboxed, so schedule and budget are always fixed too. During iteration
planning we talk about the tasks that will be needed to transform a feature
request into working and tested software
Status meeting
In agile
projects, the "status meeting"—or iteration review—is much more
meaningful because, instead of reading a document that tells stakeholders the
progress of the project, they can actually look at working software
Feature overrun
Frequently a
feature will surprise you when you start developing it. The code takes longer
than expected, or you underestimated complexity. Here are some of the ways
teams adapt to feature overrun: Work with the customer to prioritize the
functionality in the feature and potentially reduce the scope, Accept the
discovery and continue the work into the next iteration, Cancel the feature,
and re-evaluate the feasibility of the project
Technical practice used in Agile development
The four
technical practices —simple
design, continuous
integration, ruthless automated testing, and opportunistic refactoring—
work in concert with each other. Although there are many other technical
practices, these four are critical to adaptability
Brundown Chart
Progress of
the iteration can be determined from this graph line. A flat line means that either the team is not updating its
remaining work hours, or there is an obstacle preventing progress. An upward spike means that new work was discovered
Drawing a trend line from previous completed work on a release burndown
chart indicates. Assuming
no changes to the current Sprint Backlog, a trend line from previously
completed work indicates when the remaining work will be completed.
Sprint Burndown
The Sprint Burndown is what remains
to be completed in Sprint Backlog by the Scrum Team within the Sprint plan.
The sprint burn down chart is a publicly
displayed chart showing remaining work in the sprint backlog. Updated every
day, it gives a simple view of the sprint progress. It also provides quick
visualizations for reference. There are also other types of burndown, for
example the release burndown chart that shows the amount of
work left to complete the target commitment for a Product Release (normally
spanning through multiple iterations) and the alternative release
burndown chart,[19] which basically
does the same, but clearly shows scope changes to Release Content, by resetting
the baseline.
Project Portfolio Backlog
Project Portfolio Backlog lists current and potential projects
Velocity
Velocity is
used as a planning tool and as a team diagnostic metric. It
should not be used as a performance metric in an attempt to judge team
productivity. When misused in this way, velocity can motivate wasteful and
dangerous behavior.
One of the
challenges of planning a release is estimating the velocity of the team. You
have the following three options: Use historical values, Run an iteration, Make
a forecast.
Release backlog
“A
collaborative exercise of placing user stories into iterations by using sticky
notes and flip chart paper, "filling up" each iteration (or steel
box) with no more than ten points' worth of stories in each “
This set of
features, called the "release backlog," can be used as a baseline by
which project progress is
measured. The team was involved in Release Planning.
Release Burndown
The Release
Burndown is what remains to be completed in Product Backlog by the Scrum Team
within the release plan.
Release plan
The product
of the Speculate phase is a release plan based on capabilities or stories
(features) to be delivered rather than activities (as in traditional project
plans). The release plan utilizes information about the product's
specification, platform architecture, resources, risk analysis, business con
The release planning usually
requires no more than 15-20% of the product effort
At the
beginning of the sprint cycle (every 7–30 days), a “Sprint planning meeting” is
held.
·
Select what work is to be done
·
Prepare the Sprint Backlog that
details the time it will take to do that work, with the entire team
·
Identify and communicate how much of
the work is likely to be done during the current sprint
·
Eight-hour time limit
·
(2nd four hours) Development Team:[16] hashing out a plan for the Sprint, resulting in the
Sprint Backlog
At the end of a
sprint cycle, two meetings are held: the “Sprint Review Meeting” and the
“Sprint Retrospective”
Sprint review meeting[17]
·
Review the work that was completed
and not completed
·
Present the completed work to the
stakeholders (a.k.a. “the demo”)
·
Incomplete work cannot be
demonstrated
·
Four-hour time limit
Sprint retrospective[18]
·
All team members reflect on the past
sprint
·
Make continuous process improvements
·
Two main questions are asked in the
sprint retrospective: What went well during the sprint? What could be improved
in the next sprint?
·
Three-hour time limit
·
This meeting is facilitated by the
Scrum Master
Scrum
Artifacts
Product Backlog
The product
backlog is an ordered
list of "requirements" that is maintained for a product. It
contains Product Backlog Items that are ordered by the Product Owner based on
considerations like risk, business
value, dependencies, date needed,
The product
backlog is the “What” that will be built, sorted in the relative order it
should be built in. It is open and editable by anyone, but the Product Owner is
ultimately responsible for ordering the stories on the backlog for the
Development Team.
The product
backlog contains rough estimates of both business value and development effort,
these values are often stated in story points using a rounded Fibonaccisequence.
Those estimates help the Product Owner to gauge the timeline and may influence
ordering of backlog items. For example, if the “add spellcheck” and “add table
support” features have the same business value, the one with the smallest
development effort will probably have higher priority, because the ROI (Return
on Investment) is higher.
The Product
Backlog, and business value of each listed item is the responsibility of the
Product Owner. The estimated effort to complete each backlog item is, however,
determined by the Development Team. The team contributes by estimating Items
and User-Stories, either in Story-points or in estimated hours.
Sprint Backlog
The sprint
backlog is the list of work the Development Team must address during
the next sprint. The list is derived by selecting stories/features from the top
of the product backlog until the Development Team feels it has enough work to
fill the sprint. This is done by the Development Team asking "Can we also
do this?" and adding stories/features to the sprint backlog. The
Development Team should keep in mind the velocity of its previous Sprints
(total story points completed from each of the last sprints stories) when
selecting stories/features for the new sprint, and use this number as a guide
line of how much "effort" they can complete.
The
stories/features are broken down into tasks by the Development Team, which, as
a best practice, should normally be between four and sixteen hours of work.
With this level of detail the Development Team understands exactly what to do,
and potentially, anyone can pick a task from the list. Tasks on the sprint
backlog are never assigned; rather, tasks are signed up for by the team members
as needed during the daily scrum, according to the set priority and the
Development Team member skills. This promotes self-organization of the
Development Team, and developer buy-in.
The sprint
backlog is the property of the Development Team, and all included estimates are
provided by the Development Team. Often an accompanyingtask board is
used to see and change the state of the tasks of the current sprint, like “to
do”, “in progress” and “done”.
Declaration of Independence(DoI)
A series of
principles developed by the Agile Project Leadership Network is called
Declaration of Independence.
Discounted Payback Period
Discounted
Payback Period is an adjustment of the cash flow stream to account for the time
value of money.
Schedule Performance Index (SPI)
A Ration of
Earned Value and Planned Value that can be used to calculate when a project
will be completed, or how a project is progressing is called Schedule
Performance Index (SPI)
DSDM
DSDM, or Dynamic Systems Development Method, is an iterative and incremental methodology popular in Europe. It combines a project management lifecycle and a product development lifecycle into one process. It is composed of three phases: pre-project, project lifecycle, and post-project phase
DSDM, or Dynamic Systems Development Method, is an iterative and incremental methodology popular in Europe. It combines a project management lifecycle and a product development lifecycle into one process. It is composed of three phases: pre-project, project lifecycle, and post-project phase
DSDM
projects requirements are sorted into four categories: Must Have, Should Have,
Could Have, Won’t Have. DSDM refers to this sorting as the MoSCoW rules
Agile Principle
Go fast but never hurry
All agile
approaches focus on empowered,
self-managing teams; autonomous teams do not need the day-to-day
intervention of management. Instead, if management protects a team from outside
interference, and focuses on removing obstacles in the way of creating product,
teams become highly effective and productive
Project Charter
ü Its primary
use is to authorize the start of the project
ü It provides
the project manager with authority to apply resources and expend money on
project
ü The Project
Charter can be created by the person external to the project, responsible for
the authorization of the work, or that person can delegate the creation of the
Project Charter to the project manager
Product managers
Product
managers control which features are included in the product. Development
engineers control how features are designed and implemented. Product managers
wouldn't have the authority to say, "We're running behind; let's cut
testing time." Instead, they could only say, "We're running behind,
let's cut features 34 and 68." Similarly, the development team couldn't
arbitrarily add a feature because "it would be way cool."
Development Team
The
Development Team consists of professionals who do the work of delivering a
potentially releasable Increment of Done product at the end of each Sprint.Turn
the Product Backlog items it selects into an increment of potentially shippable
product functionality.
The Scrum Team is the sole owner of the Sprint Backlog.
Definition of Done
When the
Product Backlog item or an Increment is described as "Done", everyone
must understand what "Done" means. Although this varies significantly
per Scrum Team, members must have a shared understanding of what it means for
work to be complete, to ensure transparency. This is the “Definition of Done”
for the Scrum Team and is used to assess when work is complete on the product
Increment. The same definition guides the Development Team in knowing how many
Product Backlog items it can select during a Sprint Planning Meeting.
Development Teams deliver an Increment of product functionality every Sprint.
This Increment is useable, so a Product Owner may choose to immediately release
it.
The quality criteria are captured in the definition
of done.
Sprint Backlog
The Sprint
Backlog is the set of Product Backlog items selected for the Sprint plus a plan
for delivering the product Increment and realizing the Sprint Goal. It can
contain different content types. The Product Backlog is an ordered list of everything
that might be needed in the product and is the single source of requirements
for any changes to be made to the product. The Product Backlog lists all
features, functions, requirements, enhancements, and fixes that constitute the
changes to be made to the product in future releases. Product Backlog items
have the attributes of a description, order, and estimate
Non-linear sequences
sequences are best for estimating user stories in Agile Team
Non-linear
sequences work well because they reflect the greater uncertainty associated
with estimates for larger units of work. Either sequence works well although my
slight personal preference is for the first. Fibonacci sequence is an example
of such a sequence
XP-Customer
On-Site
Customers are responsible for making business decisions. The on-site customers
point the project in the right direction by clarifying the project vision,
creating stories, constructing a release plan, and managing risks.
Agile coach
The agile
coach facilitates by creating a “container” for the team to fill up with their
astounding ideas and innovations. The container, often a set of agenda
questions or some other lightweight (and flexible) structure, gives the team
just enough of a frame to stay on their purpose and promotes an environment for
richer interaction, a place where fantastic ideas can be heard. The coach
creates the container; the team creates the content.
Agile Manifesto –High Priority
Our highest
priority is to satisfy the
customer through early and continuous delivery of valuable software.
This principle underscores the focus of delivering value to the customer. At
the end of the day, it is this philosophy of customer satisfaction that drives
agile teams.
In
high-performance teams, "the leaders manage the principles, and the
principles manage the team".
Employ
minimally sufficient - is an Agile Principle.
Principle three of Agile Manifesto mandates that
"Deliver working software frequently, from a couple of weeks to a couple
of months, with a preference to the shorter time scale".
Scrum Team
Self-organization is
not an option in Scrum; it is a core principle. Without this, high performing
teams will not happen. Self-organization does not at all imply a laissez-faire
approach; on the contrary, self-organized teams are highly disciplined. They
are encouraged to take reasonable risks and to learn through failure and
self-reflection. High trust and high commitment is an automatic outcome of
truly self-organizing teams.
Scrum Teams are
self-organizing and cross-functional. Self-organizing teams choose how best to
accomplish their work, rather than being directed by others outside the team.
Cross-functional teams have all competencies needed to accomplish the work
without depending on others not part of the team. Scrum Teams deliver products
iteratively and incrementally, maximizing opportunities for feedback.
Incremental deliveries of "Done" product ensure a potentially useful
version of working product is always available.
A Swarm is a temporary
group of team members that works together on one story to bring it to
completion.
The burn rate is
the cost of the Agile team, or the rate at which is consumes resources.
Product Owner
Successful
agile product ownership is more complex than just managing User Stories and
Product Backlog. The Product Owner maximizes the Return on Investment (ROI) and
optimizes the Total Cost of Ownership (TCO).
The product
owner leads the development effort to create a product that generates the
desired benefits. This often includes creating the product vision; grooming the product backlog;
planning the release; involving
customers, users, and other stakeholders; managing the budget; preparing
the product launch; attending the Scrum meetings; and collaborating with the
team.
Good Product
Owners understand the collaborative grooming fosters an important
dialogue among all participants and leverages the collective intelligence and
perspectives of a diferce group of individuals. Good Product Owners also know
that by involving the diverce team members in the grooming, they ensure that
everyone will have a clearer, shared understanding of the product backlog, so
less time will be wasted in miscommunications and handoffs. Such collaborative
efforts also go a long way toward bridging the gap between business and
technical people.
The Product
Owner and The Development team provide clarification of the Backlog Items
During Planning Meeting and Sprint as it might be not fully known
everything or specified at the start of the sprint.
The Product
Owner acts as the single voice of stakeholders and represent their needs.
Running Daily Scrum is a responsibility of the Scrum Master. Updating
a Sprint Burndown is a responsibility of the Development Team as
well as prioritizing activities.
Process changes are owned by the
team, whereas product changes are owned by the
customer
A Sprint can be cancelled
before the Sprint time-box is over. Only the Product Owner has the
authority to cancel the Sprint, although he or she may do so under influence
from the stakeholders, the Development Team, or the Scrum Master
Scrum Master
The Scrum
Master encourages the Scrum Team to improve, within the Scrum process
framework, its development process and practices to make it more effective and
enjoyable for the next Sprint. During each Sprint Retrospective, the Scrum Team
plans ways to increase product quality by adapting the Definition of “Done” as
appropriate.
Sprint Planning Meeting
The Sprint
Planning Meeting is time-boxed
to eight hours for a one-month Sprint. For shorter Sprints, the event is
proportionately shorter. For example, two-week Sprints have four-hour Sprint
Planning Meetings.
A Sprint Review
A Sprint Review is held at the end of the Sprint to inspect the
Increment and adapt the Product Backlog if needed. During the Sprint Review,
the Scrum Team and stakeholders collaborate about what was done in the Sprint.
Based on that and any changes to the Product Backlog during the Sprint,
attendees collaborate on the next things that could be done. This is an
informal meeting, and the presentation of the Increment is intended to elicit
feedback and foster collaboration.
sprint
burndown
The sprint burndown
chart is designed to help the team monitor its progress and be a leading
indicator of whether it will meet its commitment at the end of the sprint. The
classic format requires teams to estimate the duration of each task in hours
and on a daily basis to chart the total remaining hours for all uncompleted
tasks.
Sprint Goal
output from a Sprint Planning Meeting provides the Development Team with a target and overarching direction for the Sprint
output from a Sprint Planning Meeting provides the Development Team with a target and overarching direction for the Sprint
iteration
An iteration is the
full cycle of design-code-verify-release practiced by XP teams. It's a timebox
that is usually one to three weeks long.
Iteration H is also
referred to as Hardening Iteration.
Product Burndown Chart
A meta-view perspective of
product development progress.
In Scrum, the product
backlog is a "living document", available at all times during product
development.
Release Plan
Teams are not required
to have a release plan in Scrum, but they certainly have to plan the
release.
The minimum plan
necessary to start a Scrum project consists of a Vision and a Product
Backlog. The vision describes why the project is being undertaken and what
the desired end state is.
Retrospective
A qualitative approach
is also used in auditing the process, and this is referred to as the
retrospective. A recognized exercise in the iteration retrospective is to
engage the team in answering what went well in the iteration, what did not go
well, and based on this information, what changes should be made going forward
in the next iteration. Other retrospective activities may include conducting a
root cause analysis, defining team working agreements, and recording decisions
and identifying action items.
Explore
Explore
phase plans and delivers running tested stories in a short iteration,
constantly seeking to reduce the risk and uncertainty of the project
vision
The vision
meeting is designed to present the big picture, get all team members on the
same page, and ensure a clear understanding of what it is that they've been
brought together to do. The
vision defines the mission of the project team and the boundaries within which
they will work to achieve the desired results. Here the scope is defined at a very high
level.
Envision
In the
Envision phase the team creates a preliminary feature or product breakdown structure in which features are identified In the Speculate
phase, the team expands this list, and for each feature creates one
or more "story" cards that contain basic descriptive and estimating
information.
Envision determines the
product vision and
project objectives and constraints, the project community, and how the team
will work together.
Speculate
Speculate phase
develops a capability
and/or feature-based release plan to deliver on the vision.
The product of the
Speculate phase is a release plan
based on capabilities or stories to be delivered rather than activities (as in
traditional project plans).
Adapt
Adapt phase reviews the
delivered results, the current situation, and the team's performance, and
adapts as necessary.
Risks
Risks are
identified in all planning meetings: release, iteration, and daily stand-ups
Risks can be
analyzed and addressed in all planning meetings, with the focus on qualitative
analysis, not quantitative.
Mitigate — Take steps before the risk materializes to reduce the eventual
containment costs. For example, moving a feature to an earlier iteration to
ensure that it's completed
Exposure --A specific amount of time or money used for the sole purpose of
absorbing risk is called Risk Exposure.
PV
Present Value = Future Value/(1+R)n
Net Present Value (NPV)
assumes reinvestment is made at the cost of capital.
Payback
period
Payback period does not
consider the time value of money and is therefore the least precise of all the
cash flow analyses techniques.
CPI is a ratio that shows
the current efficiency of money being spent on the project; the formula is
EV/AC. A value of one means you are getting our what you put in (which is
good); less than one is bad; greater than one is good.
The process of moving future amounts
back into their present value is known as discounting. Clearly the interest
rate that is used for discounting future amounts is critical to determining the
present value of a future amount.
IRR assumes reinvestment
at the IRR rate and it the discount rate when NPV is equal to zero.
Money earned
Money earned or spent
today is worth more than money earned or spent in the future. In order to
compare a current amount with a future amount, the future amount is discounted
back into a current amount. The current amount is the amount that could be
deposited in a bank or into some other relatively safe investment and that
would grow to the future amount by the future time.
