3 C’s

CARD, CONVERSATION and CONFIRMATION

I= Independent, N= Negotiable, V= Value added, E= Estimate, S= Small=Testable
 Glossary of Scrum Terms

Scrum Roles: There are three essential roles in any Scrum project:

Product Owner Scrum has three roles: Product Owner, Scrum Master, and Team.
Product Owner: The Product Owner should be a person with vision, authority, and
availability. The Product Owner is responsible for continuously communicating the vision
and priorities to the development team.

It’s sometimes hard for Product Owners to strike the right balance of involvement. Because
Scrum values self-organization among teams, a Product Owner must fight the urge to
micro-manage. At the same time, Product Owners must be available to answer questions
from the team.

Scrum Master: The Scrum Master acts as a facilitator for the Product Owner and the team.
The Scrum Master does not manage the team. The Scrum Master works to remove any
impediments that are obstructing the team from achieving its sprint goals. This helps the
team remain creative and productive while making sure its successes are visible to the
Product Owner. The Scrum Master also works to advise the Product Owner about how to
maximize ROI for the team.

Team: According to Scrum’s founder, “the team is utterly self-managing.” The development
team is responsible for self-organizing to complete work. A Scrum development team
contains about seven fully dedicated members (officially 3-9), ideally in one team room
protected from outside distractions. For software projects, a typical team includes a mix of
software engineers, architects, programmers, analysts, QA experts, testers, and UI
designers. Each sprint, the team is responsible for determining how it will accomplish the
work to be completed. The team has autonomy and responsibility to meet the goals of the
sprint.

Burn down Charts: Burn down charts show work remaining over time. Work remaining is
the Y axis and time is the X axis. The work remaining should jig up and down and
eventually trend downward.

The Scrum books define a sprint burn down chart as a place to see daily progress, and a
product burn down chart as where to show monthly (per sprint) progress.

Daily Scrum Meeting: A fifteen-minute daily meeting for each team member to answer
three questions:

1. "What have I done since the last Scrum meeting? (i.e. yesterday)"
2. "What will I do before the next Scrum meeting? (i.e. today)"
3. "What prevents me from performing my work as efficiently as possible?"

The Scrum Master ensures that participants call sidebar meetings for any discussions
that go too far outside these constraints.

The Scrum literature recommends that this meeting take place first thing in the morning,
as soon as all team members arrive.
Impediments: Anything that prevents a team member from performing work as
efficiently as possible is an impediment. Each team member has an opportunity to
announce impediments during the daily Scrum meeting. The Scrum Master is charged
with ensuring impediments get resolved. Scrum Masters often arrange sidebar meetings
when impediments cannot be resolved on the spot in the daily Scrum meeting.

Product Backlog: The product backlog (or "backlog") is the requirements for a
system, expressed as a prioritized list of product backlog Items. These included
both functional and non-functional customer requirements, as well as technical team-
generated requirements. While there are multiple inputs to the product backlog, it is the
sole responsibility of the product owner to prioritize the product backlog.

During a Sprint planning meeting, backlog items are moved from the product backlog
into a sprint, based on the product owner's priorities.

Product Backlog Item: In Scrum, a product backlog item ("PBI", "backlog item", or
"item") is a unit of work small enough to be completed by a team in one sprint
iteration. Backlog items are decomposed into one or more tasks.

Product Backlog Item Effort: Some Scrum practitioners estimate the effort of
product backlog items in ideal engineering days, but many people prefer less
concrete-sounding backlog effort estimation units. Alternative units might include
story points, function points, or "t-shirt sizes" (1 for small, 2 for medium, etc.). The
advantage of vaguer units is they're explicit about the distinction that product
backlog item effort estimates are not estimates of duration. Also, estimates at
this level are rough guesses that should never be confused with actual working
hours.

Note that sprint tasks are distinct from product backlog items and task effort
remaining is always estimated in hours.

Product Burn down Chart: In Scrum, the product burn down chart is a "big
picture" view of a project's progress. It shows how much work was left to do at
the beginning of each sprint. The scope of this chart spans releases; however, a
release burn down chart is limited to a single release.

The following example illustrates a product burn down chart, for an example (ACME)
product:
Product Owner Role: In Scrum, a single person must have final authority representing
the customer's interest in backlog prioritization and requirements questions.

This person must be available to the team at any time, but especially during the sprint
planning meeting and the sprint review meeting.

Challenges of being a product owner:

1. Resisting the temptation to "manage" the team. The team may not self-organize in
the way you would expect it to. This is especially challenging if some team members
request your intervention with issues the team should sort out for itself.
2. Resisting the temptation to add more important work after a Sprint is already in
progress.
3. Being willing to make hard choices during the sprint planning meeting.
4. Balancing the interests of competing stakeholders.

Release: The transition of an increment of potentially shippable product from the

development team into routine use by customers. Releases typically happen when
one or more sprints have resulted in the product having enough value to
outweigh the cost to deploy it.

"The product is released to customer or marketplace obligations. The release balances

functionality, cost, and quality requirements against date commitments."
Release Burn down Chart: In Scrum, the release burn down chart is a "big
picture" view of a release's progress. It shows how much work was left to do at
the beginning of each sprint comprising a single release. The scope of this chart
is a single release; however, a product burn down chart spans all releases

Scrum Master Role: The Scrum Master is a facilitator for the team and product
owner. Rather than manage the team, the Scrum Master works to assist both the
team and product owner in the following ways:

 Remove the barriers between the development and the product owner so that
the product owner directly drives development.
 Teach the product owner how to maximize return on investment (ROI), and
meet his/her objectives through Scrum.
 Improve the lives of the development team by facilitating creativity and
empowerment.
 Improve the productivity of the development team in any way possible.
 Improve the engineering practices and tools so that each increment of
functionality is potentially shippable.
 Keep information about the team's progress up to date and visible to all
parties.

Sprint: A regular repeatable work cycle. An iteration of work during which an

increment of product functionality is implemented. By the book, iteration
lasts 30 days. This is longer than in other agile methods to take into account the
fact that a functional increment of product must be produced each sprint.

The sprint starts with a one-day sprint planning meeting. Many daily Scrum meetings
occur during the sprint (one per day). At the end of the sprint we have a sprint review
meeting, followed by a sprint retrospective meeting.

During the sprint, the team must not be interrupted with additional requests.
Guaranteeing the team won't be interrupted allows it to make real commitments it can
be expected to keep.

Out of practical necessity, some teams choose to bend this rule by declaring some team
members 80 percent available at the outset so they still have some cycles left for
"Priority One" bugs and emergencies. But this is a slippery slope and should be avoided
whenever possible.
Sprint Backlog: Defines the work for a sprint, represented by the set of tasks
that must be completed to realize the sprint's goals, and selected set of product
backlog items.

A sprint burn down chart (or "sprint burn down graph") depicts the total task hours
remaining per day. This shows you where your team stands regarding completing the
tasks that comprise the product backlog items that achieve the goals of the sprint. The
X-axis represents days in the sprint, while the Y-axis is effort remaining (usually in ideal
engineering hours).

To motivate the team, the sprint burndown chart should be displayed prominently. It
also acts as an effective information radiator . A manual alternative to this is a
physical task board .

Ideally the chart burns down to zero by the end of the sprint. If the team members are
reporting their remaining task hours realistically, the line should bump up and down
chaotically. The profile shown below is typical, and demonstrates why the "percentage
done" concept of traditional project management breaks down. Assuming we started
measuring on July 26, what "percentage done" were we on July 28?

Sprint Goals: Sprint goals are the result of a negotiation between the product
owner and the development team.

Meaningful goals are specific and measurable. Instead of "Improve scalability" try
"Handle five times as many users as version 0.8."

Scrum focuses on goals that result in demonstrable product. The product owner is
entitled to expect demonstrable product (however small or flimsy) starting with the very
first Sprint. In iterative development, subsequent Sprints can increase the robustness or
size of the feature set.
Have your team commit to goals that anyone will be able to see are met (or not met) at
the end of the sprint. At sprint review meetings, the sprint demonstration is conducted
after which the team asks the product owner whether (s)he feels the goals were met.

While some specific product backlog items may not be done at the end of a sprint, it
should be very unusual for a team not to meet its sprint goals. Scrum requires the team
to notify the product owner as soon as it becomes aware it will not meet its goals.

Sprint Planning Meeting: The Sprint planning meeting is a negotiation between

the team and the product owner about what the team will do during the next
sprint.

The product owner and all team members agree on a set of sprint goals, which is used
to determine which product backlog items to commit from the uncommitted backlog to
the sprint. Often new backlog items are defined during the meeting. This portion of the
sprint planning meeting is time-boxed to four hours.

Typically the team will then excuse the product owner from the room and break the
backlog Items down into tasks. The product owner is expected to be on call during this
phase (previously called the sprint definition meeting) for renegotiation or to answer
questions that affect the time estimates. This portion of the sprint planning meeting is
time-boxed to four hours. Sometimes teams insert placeholder tasks (with rough
estimates) for the product backlog items they don't expect to start working until later in
the sprint.

Sprint Retrospective Meeting: The sprint retrospective meeting is held at the end
of every sprint after the sprint review meeting. The team and Scrum Master meet
to discuss what went well and what to improve in the next sprint. The product
owner does not attend this meeting.

The sprint retrospective should be time-boxed to three hours.

Kelley Louie (Certified Scrum Practitioner) writes: "The sprint retrospective meeting is
an integral part to inspect and adapt process. Otherwise, the team will never be able to
improve their overall output and not focus on the overall team performance. The Scrum
Master must pay attention to this meeting and work towards resolving the impediments
that may be slowing down the team."
Sprint Task: In Scrum, a sprint task (or task) is a unit of work generally
between four and sixteen hours. Team members volunteer for tasks. They
update the estimated number of hours remaining on a daily basis, influencing the
sprint burn down chart. Tasks are contained by backlog items.

Scrum literature encourages splitting a task into several if the estimate exceeds twelve
hours.

Team: A team (or "Scrum team") is optimally comprised of seven plus or

minus two people.

For software development projects, the team members are usually a mix of software
engineers, architects, programmers, analysts, QA experts, testers, UI designers, etc.
This is often called "cross-functional project teams". Agile practices also encourage
cross-functional team members.

During a sprint, the team self-organizes to meet the sprint goals. The team has
autonomy to choose how to best meet the goals, and is held responsible for them. The
ScrumMaster acts as a guardian to ensure that the team is insulated from the product
owner.

Scrum also advocates putting the entire team in one team room.

Team Member: In Scrum parlance, a team member is defined as anyone working

on sprint tasks toward the sprint goal.

Velocity: In Scrum, velocity is how much product backlog effort a team can
handle in one sprint. This can be estimated by viewing previous sprints,
assuming the team composition and sprint duration are kept constant. It can also
be established on a sprint-by-sprint basis, using commitment-based planning.

Once established, velocity can be used to plan projects and forecast release and
product completion dates.

How can velocity computations be meaningful when backlog item estimates are
intentionally rough? The law of large numbers tends to average out the roughness of
the estimates.

User Story: A user story is a very high-level definition of a requirement, containing just
enough information so that the developers can produce a reasonable estimate of the
effort to implement it.
 10 Key Principles of Agile

1. Active user involvement is imperative: Active user involvement is the first principle of
agile development. It’s not always possible to have users directly involved in development
projects, particularly if the agile development project is to build a product where the real
end users will be external customers or consumers. In this event it is imperative to have a
senior and experienced user representative involved throughout.

Here are 16 reasons why!

 Requirements are clearly communicated and understood (at a high level) at the
outset
 Requirements are prioritized appropriately based on the needs of the user and
market
 Requirements can be clarified on a daily basis with the entire project team, rather
than resorting to lengthy documents that aren’t read or are misunderstood
 Emerging requirements can be factored into the development schedule as
appropriate with the impact and trade-off decisions clearly understood
 The right product is delivered
 As iterations of the product are delivered, that the product meets user expectations
 The product is more intuitive and easy to use
 The user/business is seen to be interested in the development on a daily basis
 The user/business sees the commitment of the team
 Developers are accountable, sharing progress openly with the user/business every
day
 There is complete transparency as there is nothing to hide
 The user/business shares responsibility for issues arising in development; it’s not a
customer-supplier relationship but a joint team effort
 Timely decisions can be made, about features, priorities, issues, and when the
product is ready
 Responsibility is shared; the team is responsible together for delivery of the product
 Individuals are accountable, reporting for themselves in daily updates that involve
the user/business
  When the going gets tough, the whole team – business and technical –
works together!

2. The team must be empowered to make decisions: The project team must be
empowered to make decisions in order to ensure that it is their responsibility to deliver the
product and that they have complete ownership. Any interference with the project team is
disruptive and reduces their motivation to deliver.

The team must establish and clarify the requirements together, prioritize them together,
agree to the tasks required to deliver them together, and estimate the effort involved
together.

It may seem expedient to skip this level of team involvement at the beginning. It’s tempting
to get a subset of the team to do this (maybe just the product owner and analyst), because
it’s much more efficient. Somehow we’ve all been trained over the years that we must be
100% efficient (or more!) and having the whole team involved in these kick-off steps seems
a very expensive way to do things.

However this is a key principle for me. It ensures the buy-in and commitment from the
entire project team from the outset; something that later pays dividends. When challenges
arise throughout the project, the team feels a real sense of ownership. And then it’s doesn’t
seem so expensive.

3. Requirements evolve but the timescale is fixed: In agile development, requirements

evolve, but timescales are fixed. This is in stark contrast to a traditional development
project, where one of the earliest goals is to capture all known requirements and baseline
the scope so that any other changes are subject to change control.

Traditionally, users are educated that it’s much more expensive to change or add
requirements during or after the software is built. Some organizations quote some
impressive statistics designed to frighten users into freezing the scope. The result: It
becomes imperative to include everything they can think of – in fact everything they ever
dreamed of! And what’s more, it’s all important for the first release, because we all know
Phase 2’s are invariably hard to get approved once 80% of the benefits have been realized
from Phase 1.

Ironically, users may actually use only a tiny proportion of any software product, perhaps
as low as 20% or less, yet many projects start life with a bloated scope. In part, this is
because no-one is really sure at the outset which 20% of the product their users will
actually use. Equally, even if the requirements are carefully analyzed and prioritized, it is
impossible to think of everything, things change, and things are understood differently by
different people. Agile Development works on a completely different premise.

Agile Development works on the premise that requirements emerge and evolve, and that
however much analysis and design you do, this will always be the case because you cannot
really know for sure what you want until you see and use the software. And in the time you
would have spent analyzing and reviewing requirements and designing a solution, external
conditions could also have changed.

So if you believe that point – that no-one can really know what the right solution is at the
outset when the requirements are written – it’s inherently difficult, perhaps even
practically impossible, to build the right solution using a traditional approach to software
development.

Traditional projects fight change, with change control processes designed to minimize and
resist change wherever possible. By contrast, Agile Development projects accept change; in
fact they expect it. Because the only thing that’s certain in life is change.

There are different mechanisms in Agile Development to handle this reality. In Agile
Development projects, requirements are allowed to evolve, but the timescale is fixed. So to
include a new requirement, or to change a requirement, the user or product owner must
remove a comparable amount of work from the project in order to accommodate the
change.
This ensures the team can remain focused on the agreed timescale, and allows the product
to evolve into the right solution. It does, however, also pre-suppose that there are enough
non-mandatory features included in the original timeframes to allow these trade-off
decisions to occur without fundamentally compromising the end product.

So what does the business expect from its development teams? Deliver the agreed business
requirements, on time and within budget, and of course to an acceptable quality. All
software development professionals will be well aware that you cannot realistically fix all
of these factors and expect to meet expectations. Something must be variable in order for
the project to succeed. In Agile Development, it is always the scope (or features of the
product) that are variable, not the cost and timescale.

Although the scope of an Agile Development project is variable, it is acknowledged that

only a fraction of any product is really used by its users and therefore that not all features
of a product are really essential. For this philosophy to work, it’s imperative to start
development (dependencies permitting) with the core, highest priority features, making
sure they are delivered in the earliest iterations.

Unlike most traditional software development projects, the result is that the business has a
fixed budget, based on the resources it can afford to invest in the project, and can make
plans based on a launch date that is certain

4. Capture requirements at a high level; lightweight & visual: Agile development teams
capture requirements at a high level and on a piecemeal basis, just-in-time for each feature
to be developed.

I personally believe Agile Development teams can build better products if they have a
reasonably clear idea of the overall requirements before setting out on development, so
that incorrect design decisions don’t lead the team down dead ends and also so a sensible
investment case can be made to get the project funded.
However any requirements captured at the outset should be captured at a high level and in
a visual format, perhaps for example as a storyboard of the user interface. At this stage,
requirements should be understood enough to determine the outline scope of the product
and produce high level budgetary estimates and no more.

Ideally, Agile Development teams capture these high level requirements in workshops,
working together in a highly collaborative way so that all team members understand the
requirements as well as each other. It is not necessarily the remit of one person, like the
Business Analyst in more traditional projects, to gather the requirements independently
and write them all down; it’s a joint activity of the team that allows everyone to contribute,
challenge and understand what’s needed. And just as importantly, why

5. Develop small, incremental releases and iterate:

How do you eat an elephant? One bite at a time!

Likewise, agile development projects are delivered in small bite-sized pieces, delivering
small, incremental *releases* and iterating.

In more traditional software development projects, the (simplified) lifecycle is Analyze,

Develop, Test – first gathering all known requirements for the whole product, then
developing all elements of the software, then testing that the entire product is fit for
release.
In agile software development, the cycle is Analyze, Develop, Test; Analyze, Develop, Test;
and so on… doing each step for each feature, one feature at a time.
Advantages of this iterative approach to software development include:
 Reduced risk: clear visibility of what’s completed to date throughout a project
 Increased value: delivering some benefits early; being able to release the product
whenever it’s deemed good enough, rather than having to wait for all intended
features to be ready
 More flexibility/agility: can choose to change direction or adapt the next iterations
based on actually seeing and using the software
 Better cost management: if, like all-too-many software development projects, you
run over budget, some value can still be realized; you don’t have to scrap the whole
thing if you run short of funds
For this approach to be practical, each feature must be fully developed, to the extent that
it’s ready to be shipped, before moving on.

Another practicality is to make sure features are developed in *priority* order, not
necessarily in a logical order by function. Otherwise you could run out of time, having built
some of the less important features – as in agile software development, the timescales are
fixed.

Building the features of the software “broad but shallow” is also advisable for the same
reason. Only when you’ve completed all your must-have features, move on to the should-
haves, and only then move on to the could-haves. Otherwise you can get into a situation
where your earlier features are functionally rich, whereas later features of the software are
increasingly less sophisticated as time runs out.

Try to keep your product backlog or feature list expressed in terms of use cases, user
stories, or features – not technical tasks. Ideally each item on the list should always be
something of value to the user, and always deliverables rather than activities so you can
‘kick the tires’ and judge their completeness, quality and readiness for release.

These are important characteristics of iterative, feature-driven development – and they’re

essential if you plan to deliver in fixed timescales

6. Focus on frequent delivery of products:

Agile development is all about frequent delivery of products. In a truly agile world, gone are
the days of the 12 month project. In an agile world, a 3-6 month project is strategic!

The iterative approach, requirements being lightweight and captured just-in-time, being
feature-driven, testing integrated throughout the lifecycle, and so on.

So how frequent is *frequent*?

Scrum says break things into 30 day Sprints. That’s certainly frequent compared to most
traditional software development projects.
Consider a major back-office system in a large corporation, with traditional projects of 6-12
months+, and all the implications of a big rollout and potentially training to hundreds of
users. 30 days is a bit too frequent I think. The overhead of releasing the software is just
too large to be practical on such a regular basis.

But consider a web site, a web-based product – or even more dynamic something like my
blog. There’s no rollout overhead – it’s an automated central deployment to all users, and
for the blog it’s a single click. No-one’s paying for the service. If something’s wrong, no-one
dies. And it can be rolled back as quickly as it’s deployed. There may be thousands of users,
even millions of users of a web site every month. But none of them need to be trained. And
you can evaluate the impact on the user experience, and the user’s behavior, through
metrics within 24 hours and on an ongoing basis.

In that scenario, 30 days is a lifetime! Competitors won’t wait. Speed-to-market is a

significant competitive edge. The value of first-mover advantage is potentially enormous.
Whilst it’s not always the case, research shows that those first to market 80% of the time
win; and end up clear market leaders.

So how frequent is *frequent enough*?

Think carefully about your own situation. Think about the two extremes I’ve described
above. Think about what’s right for you; your organization; your product; your market;
your customers. Think about what’s right for *you*, in your *particular situation*. There is
no right or wrong answer. Only what works for you, and what doesn’t.

What is fairly important is to make this a positive decision to decide what’s appropriate for
you. And then to stick, if you can, to a regular release cycle. A regular release cycle allows
you to plan. It allows your infrastructure and ops teams to plan. It allows your business
colleagues to plan. It allows your launch events, marketing campaigns, etc to be planned.
And because agile development works to a fixed timescale, these plans are assured.
A regular release cycle also allows you to learn more effectively. Your estimating might be
good, it might be bad. Hopefully it’s at least consistent. If you estimate features at a
granular level (ideally less than 1 day) and track your velocity (how much of your estimate
you actually delivered in each Sprint), in time you’ll begin to understand your *normal*
delivery rate. And when you understand this well, you’ll be surprised how predictable you
can be.

And let’s face it; managing expectations is really all about predictability. If people know
what to expect, they’re generally happy. If they don’t, they’re not happy. Maybe even
furious!

So, in agile development, focus on frequent delivery of products. And perhaps even more
importantly, focus on consistent delivery of products.

7. Complete each feature before moving on to the next:

In agile development, “done” should really mean “DONE!”

Features developed within iteration (Sprint in Scrum), should be 100% complete by the
end of the Sprint. Too often in software development, “done” doesn’t really mean “DONE!”.
It doesn’t mean tested. It doesn’t necessarily mean styled. And it certainly doesn’t usually
mean accepted by the product owner. It just means developed.

So, in agile development, make sure that each feature is fully developed, tested, styled, and
accepted by the product owner before counting it as “DONE!”. And if there’s any doubt
about what activities should or shouldn’t be completed within the Sprint for each feature,
“DONE!” should mean shippable.

8. Apply the 80/20 rule: Pareto’s law is more commonly known as the 80/20 rule. The
theory is about the law of distribution and how many things have a similar distribution
curve. This means that *typically* 80% of your results may actually come from only 20% of
your efforts!
Pareto’s law can be seen in many situations – not literally 80/20 but certainly the principle
that the majority of your results will often come from the minority of your efforts.

So the really smart people are the people who can see (up-front without the benefit of hind-
sight) *which* 20% to focus on. In agile development, we should try to apply the 80/20
rule, seeking to focus on the important 20% of effort that gets the majority of the results.

If the quality of your application isn’t life-threatening, if you have control over the scope,
and if speed-to-market is of primary importance, why not seek to deliver the important
80% of your product in just 20% of the time? In fact, in that particular scenario, you could
ask why you would ever bother doing the last 20%.

So does that statement conflict with my other recent post: “done means DONE!”? Not really.
Because within each Sprint or iteration, what you *do* choose to develop *does* need to be
100% complete within the iteration.

9. Testing is integrated throughout the project lifecycle – test early and often

Agile development relies on close cooperation and collaboration between all team
members and stakeholders.

Agile development principles include keeping requirements and documentation

lightweight, and acknowledging that change is a normal and acceptable reality in software
development.

This makes close collaboration particularly important to clarify requirements just-in-time

and to keep all team members (including the product owner) ‘on the same page’
throughout the development.

You certainly can’t do away with a big spec up-front *and* not have close collaboration. You
need one of them that are for sure. And for so many situations the latter can be more
effective and is so much more rewarding for all involved!
In situations where there is or has been tension between the development team and
business people, bringing everyone close in an agile development approach is akin to a
boxer keeping close to his opponent, so he can’t throw the big punch.

In agile development, testing is integrated throughout the lifecycle; testing the software
continuously throughout its development.

But unlike boxing, the project/product team is working towards a shared goal, creating
better teamwork, fostering team spirit, and building stronger, more cooperative
relationships. If business engagement is an issue for you, that’s one good reason to go agile
you shouldn’t ignore.

1. Revenue: The iterative nature of agile development means features are delivered
incrementally, enabling some benefits to be realized early as the product continues to
develop.

2. Speed-to-market: Research suggests about 80% of all market leaders were first to
market. As well as the higher revenue from incremental delivery, agile development
philosophy also supports the notion of early and regular releases, and ‘perpetual beta’.

3. Quality: A key principle of agile development is that testing is integrated throughout the
lifecycle, enabling regular inspection of the working product as it develops. This allows the
product owner to make adjustments if necessary and gives the product team early sight of
any quality issues.

4. Visibility: Agile development principles encourage active ‘user’ involvement throughout

the product’s development and a very cooperative collaborative approach. This provides
excellent visibility for key stakeholders, both of the project’s progress and of the product
itself, which in turn helps to ensure that expectations are effectively managed.

5. Risk Management: Small incremental releases made visible to the product owner and
product team through its development help to identify any issues early and make it easier
to respond to change. The clear visibility in agile development helps to ensure that any
necessary decisions can be taken at the earliest possible opportunity, while there’s still
time to make a material difference to the outcome.

6. Flexibility / Agility: In traditional development projects, we write a big spec up-front

and then tell business owners how expensive it is to change anything, particularly as the
project goes on. In fear of scope creep and a never-ending project, we resist changes and
put people through a change control committee to keep them to the essential minimum.
Agile development principles are different. In agile development, change is accepted. In
fact, it’s expected. Because the one thing that’s certain in life is change. Instead the
timescale is fixed and requirements emerge and evolve as the product is developed. Of
course for this to work, it’s imperative to have an actively involved stakeholder who
understands this concept and makes the necessary trade-off decisions, trading existing
scope for new.

7. Cost Control: The above approach of fixed timescales and evolving requirements
enables a fixed budget. The scope of the product and its features are variable, rather than
the cost.

8. Business Engagement/Customer Satisfaction: The active involvement of a user

representative and/or product owner, the high visibility of the product and progress, and
the flexibility to change when change is needed, create much better business engagement
and customer satisfaction. This is an important benefit that can create much more positive
and enduring working relationships.

9. Right Product: Above all other points, the ability for agile development requirements to
emerge and evolve, and the ability to embrace change (with the appropriate trade-offs), the
team build the right product. It’s all too common in more traditional projects to deliver a
“successful” project in IT terms and find that the product is not what was expected, needed
or hoped for. In agile development, the emphasis is absolutely on building the right
product.
10. More Enjoyable: The active involvement, cooperation and collaboration make agile
development teams a much more enjoyable place for most people. Instead of big specs, we
discuss requirements in workshops. Instead of lengthy status reports, we collaborate
around a task-board discussing progress. Instead of long project plans and change
management committees, we discuss what’s right for the product and project and the team
is empowered to make decisions. In my experience this makes it a much more rewarding
approach for everyone. In turn this helps to create highly motivated, high performance
teams that are highly cooperative.

Agile development does not have a separate test phase as such. Developers are much more
heavily engaged in testing; writing automated repeatable unit tests to validate their code.

Apart from being geared towards better quality software, this is also important to support
the principle of small, iterative, incremental releases.

With automated repeatable unit tests, testing can be done as part of the build, ensuring that
all features are working correctly each time the build is produced. And builds should be
regular, at least daily, so integration is done as you go too.

The purpose of these principles is to keep the software in releasable condition throughout
the development, so it can be shipped whenever it’s appropriate.

In agile development, there’s a belief that sometimes – maybe even often – these things are
only really evident when the software can be seen running. By delivering small incremental
releases and by measuring progress only by working software, the acid test is seeing the
software and only then can you really judge for sure whether or not it’s good quality.
Agile testing therefore calls for more judgement from a tester, the application of more
expertise about what’s good and what’s not, the ability to be more flexible and having the
confidence to work more from your own knowledge of what good looks like. It’s certainly
not just a case of following a test script, making sure the software does what it says in the
spec.

10. A collaborative & cooperative approach between all stakeholders is essential

Scrum is an agile way to manage a project, usually software development. Agile software
development with Scrum is often perceived as a methodology; but rather than viewing Scrum
as methodology, think of it as a framework for managing a process.

In the agile Scrum world, instead of providing complete, detailed descriptions of how
everything is to be done on a project, much of it is left up to the Scrum software development
team. This is because the team will know best how to solve the problem they are presented.

This is why in Scrum development, for example, a sprint planning meeting is described in terms
of the desired outcome (a commitment to a set of features to be developed in the next sprint)
instead of a set of Entry criteria, Task definitions, Validation criteria, Exit criteria (ETVX) and so
on, as would be provided in most methodologies.

Scrum relies on a self-organizing, cross-functional team. The scrum team is self-organizing in

that there is no overall team leader who decides which person will do which task or how a
problem will be solved. Those are issues that are decided by the team as a whole.

And in Scrum, a team is cross functional, meaning everyone is needed to take a feature from
idea to implementation.

Within agile development, Scrum teams are supported by two specific roles. The first is a Scrum
Master, who can be thought of as a coach for the team, helping team members use the Scrum
process to perform at the highest level.
Scrum Roles

Agile Vs Iterative Vs Waterfall