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”
·
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
·
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.
thank you very much.
ReplyDeleteNice Blog!! .......PMP
ReplyDelete