THE COMPLETE GUIDE TO:

AGILE PROJECT MANAGEMENT, SCRUM AND KANBAN

NEXTGEN
ACADEMY
WELCOME TO OUR WORLD
This book has been written, created and Together, we have helped companies produce
produced by Nextgen Academy. everything from large scale Video-games to
smaller startup projects.
We create and teach high quality courses for
business professionals in areas of education Our experience tells us that having a good
that are needed to improve company processes foundation is everything and this is exactly what
and productivity for the world of tomorrow. you will be getting!

We don't just stop there. We also consult We will take you on an Agile journey through all
actively within current projects, organizational of the philosophy and thinking behind it to, how
shifts and companies who are on their digital to practically apply your newfound knowledge
transformation journey. to grow your own business or shine like a star
within your organization.
Our experience takes us from Europe to the
Middle East and South East Asia, working with
some of the worlds largest Airlines and
Entertainment companies.
LEt’s jump in!
4 WATERFALL AND AGILE
13 4 CORE VALUES OF AGILE
17 THE 12 PRINCIPLES OF AGILE
34 PLANNING YOUR PROJECT
56 STARTING OUR PROJECT
71 PROBLEM DETECTION & RESOLUTIONS
79 YOUR AGILE TOOLBOX
92 THE Scrum product owner
94 The product backlog
98 Product prioritization
102 PRODUCT ROADMAP
105 PRODUCT VISION
115 RELEASE MANAGEMENT
A COMPARISON BETWEEN

WATERFALL AND AGILE

 When your organization starts preparing for a Project,
they also discuss what methodology would be the

IN THIS CHAPTER most beneficial to them. Obviously it’s a cause for a lot
of presentations in board rooms as well as number

WE WILL: crunching and planning.

What we must generally embrace as a fact here is that

Waterfall and Agile are not different styles of Project
• EXPLAIN WHAT WATERFALL IS AND THE BENEFITS Management. They are as mentioned before,
OF USING IT AS A PROJECT MANAGEMENT development methodologies.

METHODOLOGY These two methodologies compared to each other

offer different kinds of approaches. Waterfall is usually
• LEARN THE DIFFERENCE BETWEEN AGILE AND called the “traditional” approach and as we will explore
WATERFALL later In this book, Agile is a often implemented using
“Scrum or Kanban”.

• BUILDING A CAR USING AGILE AND WATERFALL AS

A COMPARISON Both of these development methodologies have been
around for a long time and have rolled out successful
projects each on their own.

Waterfall is what you would describe an approach that

follows a familiar track - linearity. The sequence of
which Waterfall Projects are usually ran are these:
Waterfall is what you would describe an approach that
follows a familiar track - linearity. The sequence of
which Waterfall Projects are usually ran are these:

WATERFALL TIMELINE EXAMPLE

 Positive Negative
• Both Parties (Customer vs Developer) need
to agree on what will be delivered before • So, as we look at Waterfall as a heavily
the actual implementation of work. This orientated towards requirements gathering
makes the planning and design as well as Stakeholder availability, the
straightforward and you can expect very requirements gathering phase dictates what
few changes.
the rest of the Project will look like. There is
• Progress is measured through the full very little to no room for flexibility.

scope of work. The ROI and processes • Stakeholders and Customers are not always
have already been guaranteed before the able to visualize what blueprints, wireframes
work commences.
or mockups will look like as the final
• Design is an earlier phase than most other product. Most end users have difficulties
phases in these projects. This means that it pairing these with the written requirements
lends itself well to where components need given prior to Project start.

to be built or designed. For instance, • Changes become increasingly difficult and

television electronics, car seats etc…
costly to develop further into the project as
• Since all the requirements and obstacles Waterfall is based purely on requirements
are known beforehand, it provides a more that have been set months - maybe a year
complete image for the engineers and very in advance.
little area for errors.
 COMPARING WITH AGILE

As we will understand later in this course and in this book, Agile is an iterative team-based approach to
development.

The approach especially emphasizes delivering value fast rather than later. Instead of working in month
long projects where one big package of delivery is shipped off, Scrum which is the project management
tool for Agile, boxes these phases into something called “Sprints”. Each “Sprint” has a defined duration
and deliverables are prioritized by business value and determined by the Product Owner/Manager.

At the end of this Sprint which usually lasts for 10 days, work can be reviewed by the entire team. In
comparison to Waterfall, Agile relies heavily on frequent customer involvement - especially during Reviews
and Task Planning.

package of delivery is shipped off, Scrum which is the project management tool for Agile, boxes these
phases into something called “Sprints”. Each “Sprint” has a defined duration and deliverables are
prioritized by business value and determined by the Product Owner/Manager.

At the end of this Sprint which usually lasts for 10 days, work can be reviewed by the entire team. In
comparison to Waterfall, Agile relies heavily on frequent customer involvement - especially during
 Positive Negative

• The customer frequently sees work being • Agile as we have explored, is a time boxed
delivered within Sprint Review sessions delivery and allows for changes and
(within 10 days). Changes and decision can reprioritization. This means that delivery items
be made throughout the project.
might not be able to be completed within the
• There is a strong sense of ownership team planned sprints.

wide as the team works together daily to build • Additional Project costs can occur due to
the Product.
additional features being requested
• Agile prides itself in delivering high business throughout the project.

value and working software - thus making it • There is a risk for a possible reduction of
easy to produce a basic version of said quality due to frequent refactoring if the full
software that can be timed with business scope is not considered in the architecture or
goals such as marketing etc..
design.

• Development is more user-focused as there is

no single point in time for requirements - but
every day can be a new requirement day
which can be sectioned into future sprints.
 WATERFALL APPROACH

Let’s say we are a car manufacturer who have decided we are going to
bring the next generation of electric cars onto the market. Years of Design

research has gone into bringing this electric car to life and we are
almost ready for Production. So far, the entire company has seen the
blueprints and everyone is ecstatic.

As a car manufacturing
Development TESTING
company would like for our car
to be produced within 12 months.
All of our requirements have
been shipped to our
factories.

Shipped and Done

AGILE APPROACH

Team Client
We want to build an
The client is completely involved amazing electrical car but
in the process together with the we will work in Sprints so that
we can deliver value the
team.
fastest way possible. Ok?
They deliver the highest
business value first (which is the
car).

TESTING
Iteration 1

TESTING

Iteration 2

TESTING

Iteration 3
Factor Agile Waterfall
Customer Availability Stakeholder availability throughout Customers get involved at certain
the Project is key milestones, approvals etc…

Scope Adapts well to change. Does come The pre-defined requirements are
at a cost when the Project is not key for Waterfall and works well
known in advance when changes are limited.

Prioritization Delivering Value and working The customers gets everything

software reduces risk and can show they’ve asked for if the ask is
signs of Project being “On Track”. determined within the contract and
Rapid milestone delivery increases the requirements phase.
the chance of organizational
approval.

Budget Works great with a rolling budget or Agreement and handshake upfront
when a cost is set with a limit of means that the fixed price for the
sprints. However, that means work Project stands.
can still be pending.

A cost model for Agile could be

monthly funding for instance.

Team Smaller teams in pods, that are self Team handoffs mostly happen
organized. during separate milestones that
have been achieved. Design to
development for instance.
A GUIDE AND EXPLANATION TO

THE 4 CORE 

VALUES OF AGILE
 1
IN THIS CHAPTER Individuals and interactions 


WE WILL: over processes and tools

It is getting more and more clear for people these days

• EXPLAIN ALL 4 CORE VALUES OF AGILE that the people who respond to business needs and
drive the development process are crucial next to
processes. The context of this would also mean that
process driven projects with a heavy dependency on
said processes that offer very few options for flexibility,
result in teams feeling restrained - not being able to
carry out their tasks as efficiently as they wish.

The tools we use during development and when

implementing organizational changes can prove that
most of the time. Imagine you have a development and
design team working closely with each other on a
Product. The development team is heavily reliant on the
design team to provide accurate specifications and
handovers.

If the team is stuck in processes that revolve old tools

that are not as efficient as the new found ones, that can
cause a serious risk in terms of quality and timeline - not
to mention, team morale.

 Customer Collaboration 

2 Working Software Over 
 3 Over Contract Negotiation
Comprehensive Documentation

From my own experience working in Waterfall This is where we can compare Waterfall and
Projects, I’ve seen organizations spend Agile in the clearest way possible.

enormous amounts of time on documenting the

product for development as well as coming up Negotiation or for instance “Backlog Grooming”
with requirements lists that could run up and is then the product manager and the team work
down a skyscraper in central Hong Kong.
out the details of the delivery, setting
All of these then had to go to senior milestones, expectations and deliverables.
stakeholders who had senior stakeholders and These details are obviously always up for re-
they all needed to be approved one by one. This negotiation.

is obviously a cause for a huge delay in the

development.
However, should the development model follow
Waterfall, the negotiations start before the
Agile however does not eliminate the need for project starts and ends after the project has
documentation, it just streamlines it in a certain ended. This means that the level of involvement
way where the project team does not get is very thin or non-existing during the actual
bogged down in each and every detail pre- development process.

project. The difference I’m trying to point out

here is that Agile documents all of the The Agile Manifesto describes a scenario where
requirements as user stories sufficient enough collaboration is a key value where it makes it
for the team to start working on.
easier for the development team to meet the
organizations needs.

 Customer Collaboration 

3
Over Contract Negotiation

This collaborative method usually follows a certain pattern of predictability. For instance, there are
periodic demos as well as the ceremonies following the scrum framework
 4

RESPONDING TO change 

over following a plan

When I started out as a Project Manager, I was working on an organization that was switching their
organizational mindset from Waterfall to Agile.

Before this happened, developing features or a certain type of software was regarded as an expense.
Before we moved into the development phase, elaborate plans were in place. Everything had a high
priority and could not be negotiated.

With Agile being brought into the organization, that meant our priorities could now be shifted to
iterations and new features could always be added into new ones. The Manifesto means that the view
we need to have as agile practitioners is that change provides value.

Agile’s positive approach can be summed up In this quote found in “Agile Information Systems
Development Method”

“A process or capability in which human agents determine a system development approach for a
specific project situation through responsive changes in, and dynamic interplays between contexts,
intentions, and method fragments.” Agile methodologies allow the Agile team to modify the process and
make it fit the team rather than the other way around.
A GUIDE AND EXPLANATION TO

THE 12 PRINCIPLES 

OF AGILE
 1
Our highest priority is to satisfy the customer through early and continuous delivery of valuable
software (work).

Your goal here is to focus on delivering value whether it’s software or designs or an organizational plan
forward. The means by how you do this, your scrum master ceremonies and for instance different tools
are just tools. Should you not reach your goal due to complex tools and processes, it is obviously a
bottle neck and needs to be cut or set aside. In agile, what you deliver needs to have a level of agreed
usability. This means that in that small amount of time you agree on a deliverable, let’s say 1 sprint, it
should deliver the highest business value to the product. It may not be perfect, but it needs to follow a
trajectory of iterative processes that make the product whole.

What the first method helps you do is to deliver improved work, allow costumers to evaluate the value
you’ve brought to the table and give points of feedback as well opening up for more communication
within your team, the client or the organization.

Here’s where we again refer back to waterfall project management where client contact usually happens
at the start and at the end of the project. Continuous delivery can be challenging in these environments
but breaking down work and deliver features incrementally helps delivering pieces of the project to the
customer so that they receive value.

 2
Welcome changing requirements, even late in development. Agile processes harness change for
the customer's competitive advantage

This second principle addresses a concept that traditional project management methods cannot—being
adaptive to change. In the software world or within an organization, change of scope or details in a
project often come with all sorts of risks such as missing an important client set deadline, or going over
your budgeting forecast.

The reason you need to embrace “change” is to provide value. If the change does not provide value of
any sorts, why would you do it? Well, sometimes our customers orientation towards their goals change.
Sometimes they also don’t completely understand their needs until seeing the first incremental piece of
value being delivered.

When both parties or even within an organization, stakeholders focus on value and have that mindset
across the entire project, change won’t come so difficult. Also, taking a navigational approach rather
than “it’s done”-approach means that you might get to a better destination in the end. Be prepared to
change direction and find advantages for the people we work with. Besides, change might open up
more opportunity for you and the team to do excellent work!

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

Very simple to remember but also key here is to know what we always try to deliver which is “Value”.

This principle focus on delivering the highest business value first as well as delivering a piece of iteration
that the customer can actually use while being able to attach to measurable reports from their side.
Even if we are looking at a very rough design or a rough piece of software, this could mean that it still
carries a lot of value for the organization - especially if agreed with the Product Owner.

But why deliver half baked biscuits and call it a day?

Well, work that is measurable and that provides value also offers a bridge over to more feedback. For
instance a booking widget for a website, a product details page or even a product filter, feedback gives
you and the Product Owner a basis for your continued communication. Frequent delivery and feedback
means that people get used to communicating which also builds trust. You, as the Scrum Master or
Project Manager, are including the client in the core of the project, opening yourselves up to viewing
how you work. In time, with trust and communication the next delivery also improves.

Frequently however also does not mean fast deliveries. Generally speaking, fast deliveries have a
tendency to be seen as to have lower quality due to cutting corners and delivering as what some people
refer to as half baked biscuits. Looking at all of this information about delivering work frequently as well
as receiving feedback, communicating openly the summary to all of this would be:

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

This principle focuses heavily on the value different types of cross-role communication and co-operation
can have on the project.

This mindset has you expected to work with your customer daily. Speaking directly and often with your
customer or members within your organization that you are doing the project for, increases trust,
feedback as well as the direction towards the goal.

This could also lead to “Informal improvements”. These are improvements that are generally not taken
down as action points in formal meetings but rather informal settings such as a stand up or a show and
tell where you all agree to improve the product based on the mutual understanding of the group rather
than a direction set by someone else. This type of improvement comes with passion and excitement
rather than just getting the job done.

I’ve found that mixing these methods up together with your internal team as well as the Product Owners
does help and contributes to reaching the Nirvana of “Informal improvements”

Passing updates to each other over Slack.

Create a culture of open and regular communication through catch ups and quick calls.

Invite them to the Scrum Master ceremonies such as morning stand ups.

If your customer includes multiple people, stay in touch with them and touch base with them frequently.

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

This principle touches upon the concept that creative individuals can’t flourish if they’re being
micromanaged or forced to work in an environment that stifles their creativity. For an Agile project to be
successful, a team must be given the tools they need to succeed and be trusted that they are able to do
their job. But this principle is so much more than that. It is saying that one can not work without the
other. Projects cannot be build without motivated individuals.

Building Projects means that you are working towards defined goals. These goals come with their own
sets of activities and goals as well as boundaries to work within.

Deep inside the mind of everyone launching or working within a project is the need for progress.
Knowing how to accomplish progress and success is vital to retain motivation and interest. See it as a
navigational goal. If you are constantly drifting - how do you know you’ve achieved what you’ve set out
to accomplish?

Agile and motivation live in constant symbiosis as Agile is built up looking at people first. If people are
de-motivated with poor feedback, have issues communicating and don’t show initiative, one can not
exist without the other.

Give them the environment and support they need. Any sort of development whether it’s organizational,
creative or software development requires a set of tools. Our digital landscape is ever changing with
more and more tools coming up that simplify collaboration and process. With this also comes good
support. Someone to help them solve those annoying small problems, making sure their voices are
heard. Here’s where our sense of empathy and caring for the well-being of others comes into play.

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

Face-to-face communication is always the most effective means of communication. This type of
conversation leaves no room for misinterpretation and helps you get to the point of any communication
quicker. This is especially true when a group of people are working on a project together, particularly
when speed is the goal. When you communicate effectively, you hear more, say more and and work
more efficiently. I’ve seen team behavior change and companies paying large airfare bills just to have
teams in one place.

In Agile projects, where teams work intensely on a project for short periods of time, there’s no time for a
miscommunication to occur, hence why there’s a principle on face-to-face communication.

But, I’d like to take the opportunity to also discuss Remote Working as a policy.

If a team is well connected through online ways of communicating and have built a level of trust, why
would remote working be a problem?

Remote communication can distort the normal pace of our conversations. Lacking an immediate
response, we can become distracted, second-guess ourselves, or even grow frustrated with our teams.

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

Don’t conflate brief communications and clear communications: In our efforts to be efficient, we
sometimes use fewer words to communicate. But such brevity can mean that the rest of the team
wastes time trying to interpret your messages. Spend the time to communicate with the intention of
being ultra clear.

Create intentional space for celebration: Old school birthday cakes are still important for remote
teams. Creating virtual spaces and rituals for celebrations and socializing can strengthen relationships
and lay the foundation for future collaboration.
 7
Working software is the primary measure of progress.”

This principle addresses the fact that because work is down intensely and quickly, sometimes mistakes
will be made and projects will fail. Failing fast is a terminology used a lot within the Agile industry and
does not mean success is void. It generally means that within a failure you do learn and establish
grounds for success.

There are questions you can ask yourself to assess your team’s progress:

• Is your development team burning down it’s iteration stories 100% without feeling overloaded or
under-used ?

• Is your product owner / customer satisfied with the deliveries at the end of the iteration?

• Is your team/architecture/design adaptable to change?

• Is your test coverage (unit test, integration test) coverage during the iteration satisfactory?

• Are you not leaking defects every iteration?

• Is your feature delivered being used by a large % of your target users at every invocation?
Delivering a feature that no one uses or is hardly ever used is not progress…

The point the Agile Manifesto is trying to make here is that the more you deliver, the more you learn how
to get to that certain sweet

spot. Remember when we spoke about navigation? I’ve been a part of projects where clients and
customers understand what they

really do want once they’ve seen the first bits of iterative delivery coming in.

The point the Agile Manifesto is trying to make here is that the more you deliver, the more you learn how

to get to that certain sweet spot. Remember when we spoke about navigation? I’ve been a part of

projects where clients and customers understand what they really do want once they’ve seen the first

bits of iterative delivery coming in.

This means constant refinement, delivering in usable parts as well as delivering review-able and

demonstrable parts.

Let’s say for instance you are working on a product with a list of features - much like a game. As you

deliver your prototypes that are testable you can track them with measurable goals and interactions.

If you are aiming for a certain number to attach to your KPI’s you can measure that with a workable

product - even if it is very rough at this point.

 8
Agile processes promote sustainable development. The sponsors, developers, and users should
be able to maintain a constant pace indefinitely

In traditional project management methodology, some projects require lots of work upfront and at the
end to keep them maintained, and lots of idle time. With Agile methodology, there should be a constant
amount of work.

To explain this further, Agile principles state outright that you should find and keep a pace that can be
maintained indefinitely, and everyone should have that pace. I’d love to phrase this positively, but let’s
face it, it’s a principle about not burning out.

Agile processes make sure that development is sustainable – that the inputs, velocity, testing,
processes, demands, etc. all are aimed so everyone (and I do mean everyone) involved could keep this
up forever.  This of course makes sense – once you find a doable pace you’re able to continue,
predictably, over time.  When there is deviation, you can adapt as you’ve got a stable pace going. 
When it’s sustainable you can keep delivering value.

You don’t just say “hey, let’s be sustainable” and it happens.  It’s something you work on – this principle
reminds us to commit to it, to make sure we find a pace we can all work at, together.

Sponsors are the people asking for the work. It would seem their role is obvious – don’t overload
people!  Of course it’s not that obvious.  Each of the three groups have different interactions on creative
projects.  So how can Sponsors work with the other groups?

Sponsors vs Teams

▪ Sponsors need to understand what pace Developers can work at and support it – perhaps even
push back on those pressuring them.

▪ Sponsors need to work with Developers and be available so they can both assist developers, but
also stay aware of their pace and sustainability.

▪ Sponsors should listen to Users and get feedback, finding ways to encourage sustainable
development.  This may also mean understanding User perspectives – and what they want and you
want may differ.

So what do we need to watch out for here?

▪ Sponsors overload Developers. This often fails, leads to bad blood, and the “there’s more where
that came from.

Your team vs Sponsors

▪ Give Sponsors feedback and information to help them pace themselves and pace working with you.
The more preemptively you give them an idea of what’s sustainable, the quicker they’ll get it.

▪ Help Sponsors reach a sustainable pace – they don’t do the work, they may not know what it is. You
might save them from burnout and being overly pressured – or help them find they can do more.

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

Ah, just soak that one in. By paying attention to technical excellence and good design, you become
even more adaptable, more productive – more Agile. Simple, and elegant, so as you may guess I’m
going to analyze the hell out of it. It’s not that it hides any complexity – it’s obvious – it’s that there’s a lot
of power in this that anyone can use – and Creatives have unique opportunities to take advantage of.



Note this Principle spells out that technical excellence and good design are things that one wants to pay
attention to – always. That of course seems obvious, because who wouldn’t want to pay attention to
doing things right and designing things right? But it states specifically that this enhances agility – that it
lets you act, manage, and work agilely.

When you design something well, it’s more than just a “valuable” piece of work. It delivers other benefits
that deliver agility. Let’s look at them and how they apply to creative work.

▪ Good designs prevents errors since you can get it right the first time. This means you save time
since you’ve got less revision – and aspiring to good design focuses you on listening to the client
and understanding work so you deliver value.


▪ Good designs are repeatable in part or in whole – which saves time in the future. That lets you work
faster since you’ve got other things to call on like design templates, reusable code, or helpful
checklist. This can help you in creative works because you’ve got some work done already – at
least the less predictable or more standard parts.
Good design is not necessarily the same as technical excellence.  Good Design may be about laying
things out and putting things together well, about organizing and making patterns apparent.  Technical
excellence is about attention to detail, about doing things right, and about not overdoing things. Again,
it has obvious benefits anyway, but  let’s see how it affects Agile Creativity.

▪ Technical excellence just means things are done right and done well.  This ensures not having to
redo things so you can move on – good for any form of organization, but in agile …

▪ Technical excellence builds confidence in the people you work with and deliver work to.  When
people see you do well, they trust you.  Creative works, which have many options and many
variants, require trust.

So to sum this up:

▪ Good design helps reduce unpredictability, creates repeatable elements, allows work to be easier
shared, and is just good practice.

▪ Technical excellence reduces doing things over, teaches you repeatable lessons and inspires
confidence.

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

Imagine you have a to-do list with more than 100 items on it.

In software, it’s easy to get carried away trying to achieve absolutely anything that may be possible
under the sun. However, Agile methodology states to focus on achieving only what is absolutely
essential to the project’s success in order to deliver the project as quickly as possible.

But what does this mean practically?

When the right value is delivered to people, you avoid delivering work or getting stuck in processes that
over encumber the team.

This means focusing on simplicity from the get-go, hand carrying out each task in the simplest possible
way. Don't build more than minimum required. Don't talk about features which are 4 sprints away.
Elaborate your backlog as you progress in the project, which means top items in the backlog well
refined, as you go down less and less refined.

The interesting part of this principle is that it is generally applicable. This principle is true and important
for a wide range of processes outside the software industry and can even be applied on our own
personal life. It is a principle of time management and of work optimization, and many different
expressions of this same principle are out there.

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

I’ve been on the both sides of the wall. During my time, I’ve worked with large multi-national
corporations who have a very archaic look at project management and I’ve been involved in startups
where we have been self organized and able to tackle the work ahead. But how did all of this work out
and why?

The entirety of what we’ve been reading and talking about in this section is focused on self-organizing
and a level of autonomy. From communicating, to reflecting, to analyzing and cultivating our own
organization - we are all self starters.

How this practically works is that people use their hands on knowledge to design, organize and plan. As
long as you’re delivering value, the stakeholders will appreciate your approach. People will also always
gravitate towards the structure that works for them. You don’t hold all the answers at the start, but
having a self organizing teams sets every individual out on a path to achieve just that - answers that can
bring the team and project closer together.

This approach allows for adaption. You change an adapt what works and what does not. The focus on
value will keep your team from being too distracted with other waste.

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

We have now reached the final principle together and it is as transparent as it sounds. The team
regularly reviews ways of becoming more effective and steers the ship in that direction.

The most important rule within this rule is “Regularly”. This should be a very integral part of your team
structure. You then know it’s coming, and you are ready for it. This certain catch up or “Retrospective”
as it’s called is a good time for the team to reflect over what has gone great or could go better. It gets
people into an improvement mindset. The more we learn the more we grow - together.

It also encourages lessons that can be used in the future whether it is on a project level, team level or an
individual level.

Reflecting on being more effective sounds great, but there’s  an issue.  What does it mean for your team
to be “more effective.”

It’s not an obvious question, which is why the importance is in how we answer it! How do you measure
effectiveness so you know you’re getting better.
I often solve this by asking the team how they want to measure effectiveness and then going
around until we have an agreement and a way to do it. For many it’s a simple general gut check of
“did we get the work done and signed off on” but you may find a few additional factors come in.
You may also find that it changes over time. I can’t emphasize this enough. Make sure that these
reviews lead to concrete goals for the team that you can measure, and tasks for the team or
individuals so you can say “it’s done.” I’ve seen people who do reviews insist everything be
something that can be tracked as simple as a piece of work – and I have to say it’s effective.

Make sure your team comes up with concrete suggestions that you can move on. In fact, when I
do this I review them regularly, often during other meetings and definitely at the start of the next
review.
A GUIDE AND EXPLANATION TO

PLANNING YOUR PROJECT

 So now we have come to the more practical part of this
course. In this section, you will learn how to plan your
agile projects.This is done collaboratively with the wider
IN THIS CHAPTER team and is focused on driving value and minimize
waste of time.

WE WILL: The goal is to produce value during shorter development

cycles called “Sprints” and more frequent releases than
waterfall project management. This shorter time frame
• LEARN HOW TO PLAN AN AGILE PROJECT THROUGH enables project teams to react to changes in the client’s
THE USE OF needs more effectively.

This sprint planning meeting takes place between the

• ADAPTIVE PLANNING product owner and the team members who are doing
the actual implementation of said stories. During this
• BACKLOG GROOMING meeting, the product owner and the team review the
• WRITING USER STORIES backlog as well as user stories and also how long each
task will take using story pints.

• ASSIGNING STORY POINTS AND VALUE POINTS You can develop a project scope here, but remember
that the purpose of using agile project management is to
• DECIDING ON THE HIGHEST BUSINESS VALUE be able to address changes and additions to the project
STORIES FIRST easily, so the project scope shouldn’t be seen as
unchangeable.

• CREATE OUR FIRST ITERATION

Before kicking off your agile project, you’ll make a high-
level plan for feature releases and at the beginning of
each sprint, you’ll revisit and reassess the release plan
for that feature.
 ADAPTIVE PLANNING
By adaptive planning, we look closely at ever-changing requirements in an ebb and flow of changes within
an Agile Project. This means that as long as there is value to deliver, the planning and work continues for
the duration of the project budget.

BACKLOG
DONE

Delivery

Of course when we start projects we do not just look at the next two weeks. Projects are costly and still do
require forward planning with business goals and roadmaps required for stakeholders. With these plans and
roadmaps they then go and acquire the budget for the project.

When the planning generally happens, a project is selected. The project could be a range of new features, a
new product or even organizational improvements. They’re all however geared at driving value for the
Business. At the Product Level the Product Manager/Owner plans the roadmap and vision ahead - usually a
1-2 year sustainable plan.

Release planning and iteration planning are the next branch of the tree. Release planning considers
deliverables to support the long term product plan and iteration request is the feature requests the teams
receive and deliver during the course of each iteration.
 ADAPTIVE PLANNING
To begin with, requirements are understood at a very high level and thereafter, the rest of the planning is
driven by priority. As a rule, lesser time is spent on figuring out the details of those requirements that do not
have a very high priority. High priority bigger requirements are split into smaller ones so that details can be
explored. Only relative size estimates (at a high level) are done at this point to get an idea of how "big" the
work is. Once the work is quantified, tasks and effort are estimated for the highest priority requirements.
That gives an idea of how much the Team can deliver in a Sprint. This idea is tested in the first Sprint and
gives the Team a better understanding of its Velocity (or the size it can deliver in one Sprint). 

- Evolving plan, scope driven by budget and/or time

As the Product Backlog evolves, the size estimates are done for newly added requirements. The Product
burndown chart shows how much work is remaining based on the revised scope in the Product Backlog.
The work remaining is controlled usually by removing some low priority requirements (of size equal to the
added requirements) from the scope. This ensures that scope is managed continuously based on highest
priority requirements.

Adapting the plan in this manner helps in providing better visibility to all stakeholders by tackling important
issues, such as:

• How do we deliver what is most important for the customers?

• How do we address customer feedback on what has been already delivered?
• What are the key changes that we need to make?
• Have we addressed all the key risks for the project?
• How much work is remaining for the project? Do we need to adjust the project scope?
 

 ROLLING WAVE PLANNING

During this planning method the plan Traditional Project

evolves as the project progresses. This
high level plan includes estimates and
tasks to be done. The details of the ANALYSIS Analysis
project need to be constantly revised to
make sure they stay valid and current.
DESIGN Test

The immediate project details 1-8 weeks

CODE Design
might be very fine grained and detailed
but anything further down is known as
ROM. ROM (Rough Order of Magnitude), TEST Code
must be continuously worked on as more Fixed
details regarding the tasks and the project
emerges.
One-Off Continuous

What we are trying to prove with Rolling

Wave Planning is to improve our accuracy
of planning and explore current-future
opportunities.
 MOBILE APP EXAMPLE

So to create some context around what

this next part of the course will include, 好好

let’s say that we are building a mobile app

for an online store called Hao Hao.
Hao Hao
This mobile app is an online shopping app
where you can buy t-shirts, pick sizes,
check out, paid for and have the items
shipped to you.



During the planning process we will use
Hao Hao as an example for story points,
$100 $100
value points.

$100 $100
 ESTIMATIONS

Estimations have always been somewhat shrouded in mystery. We generally are not great at
estimating our tasks as there could be meetings, dentist appointments and other things that can
make our estimations seem like guesswork.
As a best practice we usually look at past successes to plan for future velocities. For instance: if we
are able to deliver X Features in the previous iteration, we are then able to deliver X Features in the
current cycle. But what do we do if we don’t have a previous velocity in this brand new project?

Simple. Estimate based on experience but still keep the complexity of the tasks in mind.

While we are creating these estimations based on our own experiences, we also always refer to
something called User Stories and Story Points.

Before we jump into all of that however, let’s take a look at:

What is a User Story and who do we write onE?

What are Story- and Value Points?

 Writing User Stories

A user story is a method used in Agile software development to capture a description of a software
feature from an end-user perspective. The user story describes the type of user, what they want and
why. A user story helps to create a simplified description of a requirement.

An Agile user story is meant to be short, usually fitting on a sticky note or note card. The user stories
should be written by the business in the language of the customer so that it is clear to both the
business and the development team what the customer wants and why he/she wants it. To write
meaningful User Stories, we describe them as INVEST.

• I – Independent – (stories should be as far as possible independent so each of

them could be developed and delivered separately.

• N – Negotiable – (User Stories should discussable further and there should be

space of negotiation)

• V – Valuable – (User Stories should result in adding value to the customer)

• E – Estimable – (User Stories should be understandable enough so could be

divided into the task and could get estimated)

• S – Small – (User Stories should not be too big, usually should be done in 40
hours of work)

• T – Testable – (User Stories, usually have acceptance criteria to test if they fulfill
customer’s needs)
 Writing User Stories As a shopper, I want to review
my cart so I can make
adjustments prior to checkout

• View quantities and items In the

In order to really cook up this User Story properly, we need to write cart

something called an “Acceptance Criteria”. The acceptance criteria is a

• See a total cost before tax and
must have ingredient for a user story. 
shipping

Acceptance criteria is a checklist that determine if all the parameters of • Remove items

a User Story and determine when a User Story is completed and working, • Adjust quantity of items
before the developer can mark the User Story as ‘done’.

• Click to navigate to a product

detail page

As a shopper I want to check out

so I can get my Products shipped As a User, I want to view a list of
to me Products so I can select some to
purchase
• Trigger checkout from any page, if
• See a thumbnail image for each “As a user, I want to see a
there are items in the cart

product
notification whenever a new
• Enter a shipping address, billing product comes into the store”
address and credit card number
• Click to view details for Product

• Add to cart from detail page

• See the notifications pop up
• Show confirmation message after
finalizing
on the screen
• Search for Product

• Verify Payment via our payment • Click to view a selection of

• View Products by Category

processor
notifications
• Add straight to cart from the
notification

 STORY POINTS

Story Points consist of three components that The Fibonacci sequence divides numbers
we need to consider whenever we are reviewing into 1,2,3,5,8,13,21.

our user stories or wanting to estimate. These

Looking at this scale, the difference between 1
are: Risk, Complexity and Repetition.

and 2 doesn’t seems o great. But if you look at 3

To find what our Base story looks like, we search upwards, you start noticing a significant
or a what is a very core and simple task that difference.

correspond to the value driven development

we’ve worked out together with the Product A general practice for developing story points
Owner and assign it 1 story point. This will be and pairing them with your user stories is to
our foundation going forward.
draw a table. Within this table you have your set
story points 1-21.
The Fibonacci sequence of numbers is the more
widely used way of story pointing. The reason
for using this scale because we are great at
comparing sizes of iterations or tasks needing to
get done rather than values such as hours. You
have probably been in a room where people say
that certain tasks are “Easy or Hard” to
accomplish. Well, that is the perfect reason why.
 STORY POINTS

Risks Complexity Repetition

Unclear Demands.
These are the efforts involved I developing Monotonous Tasks without any risk or
Dependance on 3rd Party.
a particular feature. complexity.
Uncertainty in the future.

Examples: Examples: Examples:

• Our stakeholder hasn’t signed the SOW • Before we start developing, we need to • Tasks that don’t require much work at all.
Agreement.
understand how a certain part of the IT Changing color on a logo or shifting a
Infrastructure works.
button to a lower part of a box.
• We still have to source additional
developers.

• Stakeholder is unavailable.
 STORY POINTS

Story Points consist of three components that The Fibonacci sequence divides numbers
we need to consider whenever we are reviewing into 1,2,3,5,8,13,21.

our user stories or wanting to estimate. These

Looking at this scale, the difference between 1
are: Risk, Complexity and Repetition.

and 2 doesn’t seems o great. But if you look at 3

To find what our Base story looks like, we search upwards, you start noticing a significant
or a what is a very core and simple task that difference.

correspond to the value driven development

we’ve worked out together with the Product A general practice for developing story points
Owner and assign it 1 story point. This will be and pairing them with your user stories is to
our foundation going forward.
draw a table. Within this table you have your set
story points 1-21.
The Fibonacci sequence of numbers is the more
widely used way of story pointing. The reason
for using this scale because we are great at
comparing sizes of iterations or tasks needing to
get done rather than values such as hours. You
have probably been in a room where people say
that certain tasks are “Easy or Hard” to
accomplish. Well, that is the perfect reason why.
 QUICK TO DELIVER AND MINIMAL I know exactly what needs to be done,
1 COMPLEXITY
•
and it’s going to take me little time.
QUICK TO DELIVER AND SOME I mostly know what needs to be done,
2 COMPLEXITY
•
where improvements/changes need to
be implemented, and it’s going to take
me some time.


MODERATE TIME TO DELIVER, I have a good idea what needs to be

3 MODERATE COMPLEXITY, AND
•
done, and it’s going to take me a bit of
POSSIBLY SOME UNCERTAINTY time.
LONGER TIME TO DELIVER, HIGH I know what needs to be done at a
5 COMPLEXITY
•
high level, but there is a good amount
of work due to complexity Big
unknowns we’ll discover as we get
into the work.
LONG TIME TO DELIVER, HIGH I understand the concept and the
8 COMPLEXITY
•
goals, but it will take a while to deliver
due to amount of work, complexity,
and unknowns.


• If we have an 8, we should breaking

them into smaller tasks/issues with
smaller point values and minimize the
complexity.
LONG TIME TO DELIVERY, HIGH Similar to an 8; this should definitely
13 COMPLEXITY
•
be an epic, and requires discussions
around how to accomplish.

VERY LONG TIME TO DELIVERY, VERY Similar to a 13; this should definitely
21 HIGH COMPLEXITY
•
be broken down into smaller pieces
and researched.

 VALUE POINTS
Why?

In Agile Software Development, we break Because when we measure value there are so
projects down to User Stories and Tasks. We many reasons for doing something – not all of
then define a minimum feature set Minimum them will offer an immediate financial return:

Marketable Feature and attempt to schedule

development in a way that maximizes Business Some examples of that are:

Value early on.

• Strategic – if we don’t make this

investment, we will no longer be able to
So, what happens when you need to measure maintain our market share and will fall
the value of a User Story?  What if there’s no behind.

direct financial return associated the task at

hand? The reality is that this would be an • Compliance – if we don’t make this
unrealistic expectation due to the time and effort investment, we could be in breach of the
involved and the level of granularity we need to certain regulatory laws.

go into. Remember in Agile, we don’t want to • Revenue Generation– if we don’t make this
get bogged down with documentation or investment, we’ll miss out on a chance of
processes. 
 creating a significant return of investment.



So what do we do now? • Risk Management – if we don’t make this
investment we could be in a position where
we wind up with a dissatisfied stakeholder.

We can use Value Points in hopes to simplify

the process of measuring relative value. This • Cost Avoidance– if we don't make this
scale uses the standard Fibonacci Sequence: investment, we could realise additional
1,2,3,5,8,13,21,34,55,89 as a metric. costs in the future.
 VALUE POINTS

Value Points can offer a useful tool to help with the prioritization process e.g. you can plot effort against
value to maximize delivery of those stories delivering the highest amount of value for each unit of effort.

Value Points can also empower the development team to identify the most appropriate solution for a
particular user story – e.g. the value’s low, so I’ll not spend as much time on it as one of the higher value
cards.
 PRACTICAL EXAMPLE

So now we want to start estimating our work using Story Points and Value Points!

For that, I pick the easiest task out of the bunch and also the most complex one and build a scale out of
it.

I start with the lowest number (1) and choose 21 as my maximum story point value.

I know this sounds like a lot but stick with me here. It is because 21 is a fibonacci number with a very high
value that tells me I need to break tasks down. However, for me to get to that point, I need to deliver value
to myself first and complete a certain amount of these tasks to be able to break down the 21 task have
story pointed.

With this said, let’s take a look at an example scale. The tasks distributed across the scale aren’t as
complex or easy as they seem, they are just there to offer you a measurement of how the scale would
work. In this scale on the following page, you will see how I’ve distributed the points across Business
Value and Story Points.

PRACTICAL EXAMPLE
PRACTICAL EXAMPLE

“As a User I want to check out “As a User, I want to see a

so I can get my Products notification whenever a new
shipped to me” product comes into the store”

SP Value: 8 SP Value: 21
BP Value: 13 BP Value: 3

“As a User, I want to review my

“As a User, I want to view a list
cart so I can make adjustments
of Products so I can select
prior to checkout”
some to purchase”

SP Value: 13
SP Value: 3
BP Value: 21
BP Value: 21
 PRACTICAL EXAMPLE

Easy right? Well we are not completely done yet.

My high value stories take a long time to do and I

feel like I have way too much work on my hands.
That’s why we can always look at a third value 好好

which is called “Bang for the Buck” or “Total Hao Hao

Business Value”. We are doing this because again -
we are looking at how to deliver the most value in
the shortest time.

By taking the value point and dividing it by the

story point it measure the bang for the buck. Take $100 $100
all of your story points and your value points, order
the story sequence to the highest and the lowest
bang for the buck score. It will give you a sequence
to follow.

In order to do this, we take the Value Point and $100 $100

divide it with the Story Point.

Currently our Backlog looks like this:

 PRACTICAL EXAMPLE

First, let’s take a look at our Backlog. Currently our Backlog

looks like this:
User Story Story Point Business Value Total Business Value
“As a shopper I want to 8 13 1.625
check out so I can get my
Products shipped to me”
“As a user, I want to see a 21 3 0.14
notification whenever a new
product comes into the
store”
“As a shopper, I want to 13 21 1.615
review my cart so I can make
adjustments prior to
checkout”
“As a User, I want to view a 3 21 7
list of Products so I can
select some to purchase”
 When we have completed this simple task, we need to now
PRACTICAL EXAMPLE start looking at ordering the highest bang for the buck score
to the lowest one like so:

User Story Story Point Business Value Total Business Value

“As a User, I want to view a 3 21 7
list of Products so I can select
some to purchase”
“As a shopper I want to check 8 13 1.625
out so I can get my Products
shipped to me”
“As a shopper, I want to 13 21 1.615
review my cart so I can make
adjustments prior to
checkout”
“As a user, I want to see a 21 3 0.14
notification whenever a new
product comes into the store”
 PRACTICAL EXAMPLE

This gives us a sequence for us to follow.

Sometimes, a couple of stories need to be
Iteration 1 Story Point Business Value Total Business
delivered before others, such as complex Value
designs or complex backend systems.
“As a User, I 3 21 7
This calculation however happens with every want to view a
list of Products
single iteration.
so I can select
some to
Now, let’s start looking at how we plan our purchase”
iterations based on highest business value first.

“As a shopper I 8 13 1.625

Let’s look at how we calculate this little formula want to check
out so I can get
called Velocity. my Products
Let’s say we’ve managed to complete these two shipped to me”
stories within our first iteration.
TOTAL 11 34 8.625

We are now looking at a total of 11 Story Points

delivered as well as 34 Value Points delivered.
The duration for our 11 Story Point delivery
took 10 days. This means that we can only
deliver 11 story points in future iterations.
A GUIDE AND EXPLANATION TO

STARTING 

OUR PROJECT
 We’ve previously discussed how you plan your projects
but within Agile, which is a development methodology,
there are also two very well known Project Management
IN THIS CHAPTER methods to use. They’re called


WE WILL:
Scrum and Kanban. Both adhere to the Agile Principles
but do go about work a little bit differently. They are
however both iterative systems that rely on process
flows and reduce waste.

It is important to mention that teams can adopt a mix of

• LEARN ABOUT KANBAN AND SCRUM these two systems.

• THE DIFFERENT ROLES WITHIN A SCRUM TEAM 

For us to truly understand the benefits of both and what
ceremonies are generally included, we will use ‘Hao
Hao’ as an example to see how we would develop the
app using either methodology or a mix of both.

 KANBAN

Kanban Teams generally centralize their work around a In

Kanban Board. This tool is a whiteboard, a wall or To Do Done
Progress
anything you can put sticky notes on. They can be
virtual or physical but they’re both a crucial feature in
visualizing and tracking the amount of work and
progress being made.

With that being said, all blockers and dependencies

are immediately identified as well as resolved.

If we look at a basic kanban board like the one below,

we will see that it follows three columns. To do, in
progress and Done. There are however more detailed
boards with items such as “Code Review.

The main purpose of presenting work as cards is for the

whole of your team to be able to track any progress of
work in a visual manner.

These cards hold critical information as well as the work

that involves in creating and solving the task/problem as
well as an estimation of how long that item of work will
take to complete. (Remember that the estimation we
have done does not change. We still use Story Points).

 KANBAN

The main purpose of presenting work as cards is for the Cycle Time instead of Sprints

whole of your team to be able to track any progress of The Lead time is the time from the moment
work in a visual manner.
when the request was made by a client and
These cards hold critical information as well as the work placed on a board to when all work on this
that involves in creating and solving the task/problem as item is completed and the request was
well as an estimation of how long that item of work will delivered to the client. So it's the the total
take to complete. (Remember that the estimation we’ve time the client is waiting for an item to be
done doesn’t change. We still use Story Points).
delivered.
Kanban also allows for great planning flexibility as the The Cycle time is the amount of time, that the
Product Owner can freely add tasks or remove tasks team spent actually working on this item
within the backlog of work. As long as we still follow the (without the time that the task spent waiting
Business Values we’ve identified in the previous section, on the board). Therefore, the Cycle time
we are still sure we are maximizing value for our should start being measured, when the item
customers. This means that we don’t generally look at task enters the "working" column, not earlier.
fixed durations such as Sprints. We rather look at
Cycles.
Lead Time

Ticket Created Start
 Ticket 


Work Live

Cycle Time
 Like everything else in Agile, there are principles and
KANBAN values to adhere to. Kanban has a whole 8 of them that
we will explore in detail below:

Start with what you do now: Respect the current process,

1 Kanban does exist on it’s own but
3 roles and responsibilities 

it is not mutually exclusive to other As Kanban encourages incremental
workflows. It can peacefully co- changes, it still does not instill fear
exist and bring issues to light. It that would stifle progress and
does not require sweeping determination. It allows for broad
changes, just a bit of self organizational support and small
organizing. course corrections that save
projects from large processes.
organizing.

Agree to pursue incremental, Encourage acts of Leadership

2 evolutionary change 4 We don’t need to be leaders or
Kanban does exist on it’s own but Managing Directors to implement
it is not mutually exclusive to other this change. The leadership comes
workflows. It can peacefully co- from the teams themselves.
exist and bring issues to light. It
does not require sweeping
changes, just a bit of self
organizing.
KANBAN

Visualize the workflow: Limit WIP:

5 The most common way to visualize 7 Work in Progress means that you
your work is to use cards and have a backlog and that things
walls. Each column represents have moved from to-do. The
steps within this workflow but most critical elements are that work-in-
importantly - Progress and Value. progress at each state in the
workflow is limited and that new
work is “pulled” into the next step
when there is available capacity
within the local WIP limit. These
Manage Flow constraints will quickly illuminate
6 The whole point of introducing a
problem areas in your flow so you
can identify and resolve them.
Kanban into your organization is Limiting WIP is the cornerstone of
for it to grow and signal positive Kanban.
change. It visualizes how value is
flowing through the system. The
journey in itself is the repetition of
cycles.
KANBAN

Make Process Policies Explicit

8 An example of a policy that you can make very explicit in your project is to look
at the definition of done. In fact, it can be created for every workflow, meaning
that before items can be pulled into your cycle it needs to meet a certain
criteria. (Acceptance Criteria). 

When teams are all aligned on a preferred model of working, responsibilities,
roles and risks they are more likely to build a shared understanding of the
problems and suggest improvements.
 SCRUM

Scrum, much like Kanban is a framework that requires the teams to

work together. Self-organization as well as reflecting on team structure
and the project as a whole is key.

One of the reasons Scrum is so popular is that it’s not just a software
development methodology, but it can be used in any regard. Scrum
describes a set of meetings, tools and roles that work in symbiosis
with each other to help the teams manage their work.

We need to distinguish between Agile and Scrum for starters. Scrum

is the method of getting your work done and Agile is the entire
mindset behind this method.

Since Scrum is self contained, it helps the team evolve through

experience as it’s not uncommon for the team not know too much
about the Project. With re-prioritization built into the process, it’s not
uncommon for teams to learn and improve as they go.

Scrum is a structured framework but it’s not inflexible.

SCRUM ARTIFACTS

Increment
DEFINITION OF DONE This is the sum of all of your
Every backlogged item has an acceptance criteria that product backlog items
measures what must be met when your task is done. completed during the sprint and
Instead of always repeating these “Done” Criteria all previous sprints.

throughout every user story, we generally collect these The increment generally has a
criteria in one place and call them definition of done. 
 meaning which is:

The definition of done is a shared understanding within • It must meet the definition of
the scrum team about when work is generally done.

completed.

• Must be in usable condition

Here are a couple of examples: regardless of whether the
• Completed unit acceptance testing of the User Story.
Product Owner decides to
actually release it.
• Reviewed by stakeholder or product manager.

• All issues are fixed.

SCRUM ARTEFACTS

SPRINT BACKLOG
PRODUCT VISION This is your list of items that you
The Product Vision is an artifact to define the long term have agreed to with the Product
goal of the project or product. This vision sets the overall Manager/Owner to complete
direction and guides the Scrum Team. Everyone should within a set of time - usually
know what the Product Vision is. within 2 weeks.

During the sprint planning

session, your team together with
the Product Manager/Owner
transfer a set of tasks from the
Product Backlog into the Sprint

PRODUCT BACKLOG Backlog.

This list is maintained by your Product Manager or

Product Owner. It’s an ever moving list of features,
enhancements, fixes and it acts as a basis for your
Sprint backlog. This is your teams current and future to-
do list and is the subject of re-prioritization.
SCRUM ARTEFACTS

Burndown Chart
Burndown Charts are graphs
that give an overview of
progress that your team has
done. As tasks are completed,
the graph burns down to zero.
It’s used as a tool and a guide
during development to lead a
team to successful completion
of a Sprint on time. Updated
every day it gives a good
overview of the Sprint progress.
SCRUM CEREMONIES

Daily Scrum or Stand up

1 This is a daily meeting as the title 3 Sprint
The term sprint is used in agile project
says and it’s for team members to management, specifically in the scrum
update the whole group on their method. Generally, scrum is defined
latest progress. 
 by regular and repeatable work

 cycles.
What did I do yesterday?

What am I planning to do today?

Are there any blockers preventing
me to achieve my daily goal?
Retrospective
Sprint Review
4 Since we in Agile see self
Usually at the end of the Sprint, the organizing teams as a basis for our
2 team gets together for an informal successful value delivery, we
together document what worked,
session to view a demo of the
completed work. The backlogged didn’t work and what could work in
items that were WIP should all be the future. The point is not to focus
listed as “Done”. on what went wrong but come up
with suggestions for improvement.
 SCRUM Roles
PRODUCT OWNER
PRODUCT MANAGER
The product owner in an Agile environment
works hand in hand with the development team
Product Managers work closely with the to clarify user stories, product vision, and
development team and manage the direction of specifications, manage backlogs, and maximize
the product based on insights and research from the product’s value to the business. The product
customer feedback and market research.
owner communicates the business intentions to
The Agile product manager’s goal is to work with the development team so that they have a clear
customers and company leadership to define the understanding of why they are being asked to do
product direction. The product manager is what they do.

responsible for representing the true voice of the They are able to see the full picture:
customer. The best way to fully understand the understanding the needs of the business and the
customer’s problem(s) is to talk to customers – customer, communicating with business teams,
visit their sites, experience their day-to-day and aligning technical activities in order to
business life, and interview their staff. In doing deliver an exceptional product. Product owners
this, a product manager will gain first hand typically have a basic understanding of software
insight the customer’s struggles and will be able development, are effective communicators, and
to define features and functionality that alleviate understand the need to address customer
the pain points. Without direct field interaction problems. It is common for product owners to
with customers, it is impossible to fully hold business analyst positions prior to
understand a customer’s struggles and needs.  becoming a product owner. 
 SCRUM Roles

SCRUM MASTER
Scrum masters are the facilitators of scrum, the ScrumMaster role is to protect the Scrum process
lightweight agile framework with a focus on time- itself. The ScrumMaster is the expert on how
boxed iterations called sprints. As facilitators, Scrum works and how it should be applied. He or
scrum masters act as coaches to the rest of the she will ensure that the product owner and
team. “Servant leaders” as the Scrum Guide development team stay within the Scrum
puts it. Good scrum masters are committed to framework. By extension, the ScrumMaster can
coach the other team members on how to use
the scrum foundation and values, but remain
Scrum in the most effective manner.
flexible and open to opportunities for the team to
improve their workflow.Scrum Masters perform This is a very different role from that of a
these tasks:
traditional project manager, despite frequent
• Standups
comparisons made between the two. Project
managers are responsible for managing the work
• Sprint Planning Meetings

of project team members, and that guides their

• Sprint Reviews and Internal Consulting
own day-to-day work. For the ScrumMaster,
• Retrospectives and 1on1
however, the only formal accountability is over
the process.
• Board Administration
 
• Reporting and Blockers
 SCRUM Roles

Development Team
This leads to an obvious question: For example, each team member can take a
Who does have accountability for the people feature from the prioritized product backlog, then
doing the work? That's where the development decide individually how to execute that work.

team comes in. A typical Scrum team consists of

five to nine people and generally includes the
typical functional roles required to complete the This level of autonomy is a cornerstone of
project. In software development, that means Scrum. It encourages strong bonds between
architects, testers, developers, and designers; team members and helps create a positive
but those titles are only relevant in establishing working environment. While the idea of a team
each individual's expertise.
exists in Waterfall projects as well, in that
environment the team is functionally managed by
the project manager, rather than being self-
The team acts collectively to determine how to managed.

achieve their goals. The specific features they  

work on are determined by the priority

established by the product owner. The way they
work is guided by the Scrum process, as
monitored by the ScrumMaster. Everything else
is up to the team to manage, with the
ScrumMaster providing as much support as
needed to allow that to happen.
A GUIDE AND EXPLANATION TO

PROBLEM 

DETECTION METRICS 

AND RESOLUTIONS
 So, let’s face it. We all run into problems sometimes.
Agile isn’t by default free of errors. There’s always
IN THIS CHAPTER potential for mistakes, whether it’s over-committing,
team struggles or even problems associated to costs or

WE WILL: other factors.

This section will help you understand what potential

problems could come up and resolutions to these
problems as well. In this part of the Course we will:

• LEARN HOW TO DETECT PROJECT RISKS

• Examine and explain problems within Agile Projects
• HOW TO MITIGATE ISSUES AND SOLVE PROBLEMS and how to detect them.

WITHIN AN AGILE ENVIRONMENT

• Discuss different techniques to discover these
problems using a Fishbone Diagram, Lead time and
Cycle Time, Defects, WIP and also discover our 5
Why’s.

• Understand and demonstrate problem solving

techniques.

• Identify bottlenecks and problems using a Cumulative

Flow Diagram.
 AGILE PROBLEM DETECTION

The achievements and successes of any project relies on how rapidly and successfully the group
settles its problems. Regularly, a group that is highly focused on delivery, neglects to plan
forward and this could be the cause of potential issues. Whenever left uncertain, the issues
keeps on mounting and after some time, prompting delays and revamp, in this way wrecking the
task plan.

There are different ceremonies in Agile to recognize and address issues, in any case, the
ceremonies center explicitly around problem detection - not how to solve them. 


• Day by day Standup: the third inquiry in Daily Stand-ups– "Are there any blockers or
obstructions to finishing an assignment?"

• Retrospectives help address issues proactively, it guarantees that the teams pick up the
problems at a certain point in time and also deliver results to solve these problems.
 THE FISHBONE DIAGRAM

One particular example that comes in

mind when explaining the fishbone
diagram is “The puddle on the floor”.

In it’s essence, it is saying that the puddle

on the floor exists because of a root
cause. Instead of mopping it up and
buying more towels, the root cause needs
to be explored and fixed. These are the
steps we take to identify the root cause:

The 6 causes we need to list in the

Fishbone Diagram are often used in
Marketing. These are:

1. Product/Service
2. Price
3. Place
4. Promotion
5. People/Personnel
6. Process
 THE FISHBONE DIAGRAM - EXAMPLE

Imagine a software development company 1. Why is our app not generating sales for us?
that has been very historic at rolling our their Because we’ve lost 30% of our DAU.

VPN Software with innovative features built

into it over several years time. Revenue is
through the roof and they have millions of 2. Why is that DAU down so much?
customers all around the world.
Because we aren’t the number 1 VPN Service
During the first quarter of the new year, anymore.

their DAU (Daily Active users) plummet by

30%.
3. Why are we not the number 1 VPN Service
By applying the 5 Why’s and a Fishbone anymore?
diagram this could mean the difference
Because our servers are over capacity and results in
between “mopping up a puddle” or
users timing out.

“replacing the leaking roof.”

With only 3 questions, we’ve come to a mutual

The Product Managers might assume that the
understanding of the problem. It’s not exactly
features they have been rolling out are
mandatory to ask exactly 5 questions, it is purely an
becoming old and stale OR that their
indicative number. Together with the fishbone
backend infrastructure cannot support the
diagram we are able to visualize the problem and
amount of traffic they are getting. These
also divide it into categories.
assumptions can create a lot of problems
because without getting to the root cause,
they could be addressing the wrong
 LEAD TIME AND CYCLE TIME

We briefly explored Lead Time and Cycle Time in the

Kanban section but this will take you more in-depth.

Within Production, whether it’s software development

or manufacturing, SIP is the number of days between
feature specs being written down and delivery to
production. This is the time the Product Owner/
Product Manager have to wait for their Backlogged
Item to be designed, developed and delivered. 

Lead Time (LT) = CT X WIP
The way this calculation works is: Lead Time equals
Cycle Time or (CT) multiplied by WIP.
WIP = Work in Progress
Cycle time is the time the team needs to convert a
specific requirement into a working solution.



This usually starts when the team picks up a
backlogged item and delivers the finished work ready
and bug free.

A longer cycle time could mean that there are

bottlenecks within the project that need to be solved.
The overall Lead Time can always be reduced by not
letting the CT overrun. It demonstrates how well the
team can cope and adapt to change.
 ESCAPED DEFECTS

Escaped defects are bugs and issues not picked up

by the QA Team but rather by the end-user. This is
very common in the software development world and
especially the games industry. We all know
Escaped Defects
how many patches studios roll out before
the game comes to a point where we can 70

consider ourselves happy users.

52.5
Capturing this specific metric will help you
understand if the QA efforts for the project
35
are robust.

These defects usually come at a price. If 17.5

we think through an overall product
perspective, this could influence people’s
0
opinion of your brand.
April May June July August September October November December

Using a trend analysis, it helps identify if these

escaped defects increase or decrease over time. This
illustration shows the number of defects tracked on a
weekly basis.
 WIP - Work in progress

Let’s explore what WIP actually is and how it impacts the organization.

Work in Progress are the requirements picked up from the backlog that the team has started
working on. It equals the amount of work the team is currently engaged in.

Having a too long of a list results in:

Sunk cost: Tasks are taking too long and is failing to produce ROI.

Hidden Problems: Complex tasks that haven’t been researched or explained can make it difficult to
diagnose.

Additional Rework: Business expectations dictate a change in direction.

Anything between Backlog and Done can be called WIP. The philosophy of Kanban is to minimize
WIP by setting explicit limits, which allows downstream processes to determine when they can
consume more work.

WIP limits help focus on bottlenecks in the system and trigger appropriate corrective action. Work in
upstream processes stops if a WIP limit is reached. WIP limits ensure an emphasis on the team’s
throughput, that is, how fast products are developed by the team, rather than on individual
productivity, that is, how efficient each individual is performing.

This subtle shift in focus creates a positive synergy within the team, enables them to spend time on
innovations, and helps them transform into a High-Performance Team.
A GUIDE AND EXPLANATION TO

YOUR AGILE TOOLBOX

 In this section, we will be looking at a few tools and
methods that make your transition into agile and your
implementation of it easier to digest within your current
IN THIS CHAPTER organization but most importantly - yourself.

WE WILL: There is a wide variety of activities, software and

ceremonies to use whether you are making the
transformation or already have been engaged in an agile
way of working for a long time.

Here are the methods and pieces of software that I’ve

• LEARN ABOUT DIFFERENT TOOLS AND WORKSHOP enjoyed success with using over the years.
MODELS THAT WILL HELP YOU MANAGE YOUR
AGILE PROJECT
 TOOLS

JIRA by Atlasssian

JIRA offers a very precise way to define workflow, manage daily task and track the progress of the
work done by team. Provides with more features then Trello.

It is a great tool for Project Managers. It’s a tool where you can create projects, create sprints and
epics inside those projects, manage it by creating stories which team would work on to deliver the
product.

JIRA Gives great reports to understand the progress of the project. Helps you with total spent verses
the estimation, which us to understand the budget very preciously. These are several Diagrams to
choose from which can both highlight risk at an early stage.

The tool also helps you with configurable scrum and Kanban boards. Where you can use Scrum board
for managing your board, which you can use Kanban to manage bugs, epics in the system.
 TOOLS

TRELLO by Trello

I guess many of you could hear

about Trello, one of the most
used and well-known project
management application. It has
both free and premium accounts
that give you a great chance to
use most of the common
functions. The structure of Trello
is based on the Kanban
methodology.

All the projects are represented by boards, that contain lists. Every list has progressive cards that you
are made as drag-and-drop. Users that are related to the board, can be assigned to cards. Summing
up, it has many nice, small but not less useful features I would like to indicate: writing comments,
inserting attachments, notes, due dates, checklists, colored labels, integration with other apps, etc.
Additionally, Trello is supported by all the mobile platforms.
 TOOLS

ASANA by Asana

Asana is the ultimate task management tool. It allows teams to share, plan, organize, and track the
progress of the tasks that each member is working on. It is simple, easy in usage and is free for up to
30 users in a team. As all the previous agile project management software platforms with the main
objective in allowing us to manage projects and tasks. What is noticeable is that you don’t need to
have even an email to use Asana.

Each team can create its workplace that will contain projects and project’s tasks; each task can have
notes, comments, attachments and tags.This tool can be used as for the small processes and for the
giant ones without any limits in the industries or departments.
 TOOLS

Planning Poker
Planning Poker is a very popular technique within Scrum teams for planning. To start a session, the
stakeholder - usually the Product Manager/Owner reads a user story and describes it to the team that
is estimating.

Each person who is a part of the estimating team is

holding a deck of cards with Fibonacci values such as 0,
1 ,2, 3, 5, 8, 13, 21. I’ve seen planning cards go up to 100
but if we are defining major complexity as 21, I generally
don’t see a point in raising higher cards than this.

The team that is estimating needs to ask the Product/

Manager owners questions if things seem unclear. Once
1 2 3
clarity has swept through the room, the team present their
own individual estimates by playing 1 card from their deck of
cards. Important to note is that everyone needs to reveal their cards at the same time.

If we’re all playing the same number from our decks, that means that we are in an agreement about
the storypoint. Should we not play out the same cards, the team needs to discuss their estimates.
Once the discussion has led to a conclusion, the team then repeats the reveal process. If there is no
agreement on certain user stories, then this is the basis for further research and is held off until further
information is required.

 TOOLS

Build a City with Lego

This game is a Scrum Simulation where teams will need to practically apply all of their Scrum
knowledge onto the game.

The Material you need for the game:

• Lots of Lego.

• Product Vision: A document containing the vision to build the Lego City.

• Requirements and User Story Cards. These cards are pre-written and compiled and they relate to
various buildings and objects within the city itself.

• Planning Poker cards.

• Whiteboard or large paper to write sprint outcome and velocity on for each team.

• Pen and whiteboard markers.

• Post its to write your notes and added user stories on. Even estimates work on these too.

• Pitfall cards: Such as one of the team members is sick for 2 days.

• Rules. 



As mentioned before, the goal of the game is for every person on the team to simulate a good
understanding of how the scrum process works. The team and especially the scrum master need to
put into play what they’ve learnt before.
 TOOLS

• The timing and the ceremonies for the game looks like this although I’ve seen other variations during
my days. 


• 5 min. Preparation from the Product Vision for the Product Owner, includes sorting out the provided
stories plus adding some own or enriching some of the others.

• 5 min. Product Owner presenting the Product Vision as well as a high level presentation of the
Backlog, Teams can ask questions on stories or requirements:


And this is the timing for all of the ceremonies

Sprint #1 Sprint #2 Sprint #3 Sprint #4

Sprint Planning 
 Sprint Planning 
 Sprint Planning 
 Sprint Planning 


5 Minutes 3 Minutes 3 Minutes 3 Minutes

Development Sprint
Development Sprint
Development Sprint
Development Sprint

8 Minutes 8 Minutes 8 Minutes 8 Minutes

Review Meeting
Review Meeting
Review Meeting
Review Meeting

8 Minutes 8 Minutes 8 Minutes 8 Minutes

Team Retrospective
Team Retrospective
Team Retrospective
Team Retrospective

8 Minutes 8 Minutes 8 Minutes 8 Minutes

A GUIDE AND EXPLANATION TO

THE SCRUM 

PRODUCT OWNER
 A WHOLE NEW WAY OF LOOKING AT A PRODUCT
This book has been written, created and Together, we have helped companies produce
produced by Nextgen Academy. everything from large scale Video-games to
smaller startup projects.
We create and teach high quality courses for
business professionals in areas of education Our experience tells us that having a good
that are needed to improve company processes foundation is everything and this is exactly what
and productivity for the world of tomorrow. you will be getting!

We don't just stop there. We also consult We will take you on an Agile journey through all
actively within current projects, organizational of the philosophy and thinking behind it to, how
shifts and companies who are on their digital to practically apply your newfound knowledge
transformation journey. to grow your own business or shine like a star
within your organization.
Our experience takes us from Europe to the
Middle East and South East Asia, working with
some of the worlds largest Airlines and
Entertainment companies.
 Creating your product backlog

The Product Backlog is slightly different from the Sprint backlog as the latter one is drawn from the first
one. We know by now that the way we organize work in Scrum is - Sprints. They usually last two weeks
and before anyone heads into one there is a need for creating that Sprint Backlog which is a set of tasks
aiming to accomplish the Sprint Goal.

Since that Sprint Backlog is drawn form the Product Backlog, the Product Backlog lists all the features,
functionalities and research that support the Product. The Product Owner is usually in charge of taking
care of that Product Backlog. As with anything in Agile and Scrum, it’s ranked by value with the highest
value needing to be worked off first based on business value needs, research and tech trends to not fall
behind in the market.

A backlog that is organized in that way ensures that our work can provide maximum value for our
organization and as you can see, it needs to be constantly updated and managed. That process is called,
backlog grooming. Without updating that backlog it can go quite stale and not stay current for very long.

 Creating your product backlog

The roadmap that you are building should contain long term goals for several releases in the distant future,
however the product backlog should focus on listing work for the next release in great detail. Using Rolling
Wave Planning, we ensure that the immediate sprints are addressed and as clear as possible, and the far
distant ones will be placed lower down and details will emerge as you rush towards that specific goal.

The products that you create, let’s say a ride sharing app who’s ultimate purpose is Ride-sharing also
introduces an online wallet needs their own backlog. Still, the benefit of using one single backlog is
substantial. If your product is massive - let’s say an operating system - we could look at creating several
backlogs as we don’t want hierarchy and importance + launch times to conflict with each other.

User Stories and Epics

We’ve gone through user stories before in this book, but just to put emphasis on them, they are the tasks
you need to complete from the user’s point of view and these are the stories you work off of in your Sprint. 



Stories that are generally very large are called “Epics” and they can take several Sprints to accomplish.
These Epics are generally stories that contain several stories - could be 50-100. These user stories need to
be derived off of the Epic in order for the Sprint to begin. One cannot work off of an epic just like that.

Let’s take a look at an example

 Creating your product backlog

“As a Large Travel Website, I want a system that can determine the lowest prices depending on
variables such as seasons, so that my visitors on the website can receive the best prices”

This is obviously a huge task so it needs to be broken down into smaller user stories. For instance:

“As a large travel website, I want to set the optimal rate for flights based on what flights comparably are
charging”

Using Rolling Wave Planning, we set the higher value stories as highest in the chain but they also need to
include the most details. Let’s dig a little deeper into this so we can really drill down on what the User Story
should contain.

“As a large travel website, I want to set the optimal rate for flights based on what flights
comparably are charging”

> The function should check fares for all airports within 100km.

>> The function should give me the ability to sort fares by distance

>>> The function should give me options to sort through Price

>>>> The function should give me an option to sort through Airports as a Departure and Arrival.
 Creating your product backlog

We sometimes turn to different stories that are not needed as user stories. 

This would include work on the backend or other tasks that aren’t meant for users. For instance internal
admin dashboards or DAU dashboards that we need to keep an eye on to monitor our KPI’s. These tasks
are important to distinguish because they use something called Feature Driven Development (FDD). The
sequence to this is very simple

(Action + Result + Object). For instance if we’re looking at a regular login sequence we would look at it like
this:

(Validate + Password + User).

There are only four items that we deal with in Scrum backlogs (Sprint + Product). These are features, bugs,
technical work and knowledge acquisitions.

A good way to start building out your product backlog is to throw all of your ideas on the wall and see
which ones carry the most value. As long as you have enough value driven stories for your sprint, you are
fine. Keep it simple and break it down again - as per value.

 Product Prioritization

We’ve mentioned this before but this is key for your Product backlog. Value driven items go first, low value
or far away reaching goals come second to that. Priority ranking is key when looking through your product
backlog.

I usually use a three step formula to determine what priority everything has:

1. Critical to achieving business goals

2. Useful but not critical

3. Would be bonus if we get these items done

The definition of done is the charter that dictates whether or not your item or user story has been
successfully completed within the sprint. The acceptance criteria within this definition of done is what the
team will be looking at as a “completed” or “well done”. In order to set a clear tangible goal - shippable is
used. Once the definition of done has been met in the Sprint Review it can be moved to the done column
or whenever your PO feels that definition of done has been reached.
 Product Prioritization

So how do we create one?

Now that we know what we need to include in our backlog, how we prioritize, let’s take a look at how we
build and work with a Product backlog. To do that, we’re going to go through a thorough checklist to
ensure that we address all areas:

1. You as the Product Owner are solely responsible for the Product Backlog. You’re in charge of
maintaining it with all of your research, features and planning based on the organizations roadmap and
vision.

2. The Product Backlog is the complete list of all user stories and work items for the Product - However
you can always update it with more, change the requirements and add more insight.

3. Be as specific as possible with near sprints and goals. Distant ones can be shrouded in mystery for
now.

4. Always use the USER as a point of view

5. Include bug fixes, knowledge exchange and other technical internal work as FDD Stories.

6. You rate the value and priority of all of these stories. Your research and specific insight into customer
wants and needs drives the backlog.
 Product Prioritization

7. You don’t need to look at an estimation right now, the sprint planning session and catch ups with your
team will help you do this

8. Rank your product Backlog

9. Your Product Backlog is an ever flowing list of changes and adaptions. However, your sprint shouldn’t
change. The sprint backlog is agreed upon and only unlocked when definition of done has finally been
met.

10. Always add new work into the product backlog.

Here’s an example we can look at again:

Story Value Prio

As a shopper, I want to view a list of products so that I can select some to purchase 21 1
As a shopper, I want to review my cart so that I can make adjustments prior to checkout 21 2
As a user, I want to check out so that I can get my products shipped to me 13 3
As a shopper, I want to review my order so I can see what I’ve purchased in the past 8 4
 Product Prioritization

The way we look at the Backlog refinement process is what we refer to as the DEEP Acronym:

D - Detailed appropriately so that items at the top of the list have more detail than those at the bottom. 

E- Estimated - Each product backlog item, or at least those involved in the next release, should be
estimated by story points or time. As your team gets more work under its belt, its velocity - the rate at
which it finishes items from the product backlog - will become clearer and make estimating easier.

E- Emergent - This means the product backlog is adapted to new items or information that emerge.

P- Prioritized - All items on the product backlog are ordered with the most important ones at the top. 
 The PRODUCT ROADMAP CHART

Product roadmaps are an important product management tool. But applying them effectively can be
challenging. Roadmaps are too often focused on features, and product managers spend too much time
getting the stakeholders to agree on when which features will be developed.



A product roadmap is a high-level, strategic plan, which describes how the product is likely to develop and
grow over the next months. This creates a continuity of purpose, and it helps product managers and
product owners acquire funding for their product; it aligns stakeholders and facilitates prioritisation; it
makes it easier to coordinate the development and launch of different product; and it provides reassurance
to the customers (if the product roadmap is made public).
 The PRODUCT ROADMAP CHART

The first row of the roadmap depicted above contains the date or timeframe for the upcoming releases.
You can work with a specific date such as  1st of March, or a period such as the first or second quarter. I
find dates particularly valuable on internal roadmaps. If you use an external one, you may want to remove
the row or use loose timeframes, such as, in the first six months of 2014.

The second row states the name or version of the releases, for instance, iOS 7 or Windows 8.1.

The third row provides the specific product goal of each major release or product version, the user/
business benefit that should provide or the outcome you want to achieve. Sample goals are to acquire or
to activate users, to retain users by enhancing the user experience, or to accelerate development by
removing technical debt. Working with goals shifts the conversation from debating individual features to
agreeing on desired benefits making strategic product decisions. The development team, key
stakeholders, and the management sponsor should all buy into the goals.

The fourth row provides the features necessary to reach the goal. The features are means to an end, but
not an end in themselves: They serve to create value and to reach the goal. You can think of the features
as the output required to create the desired outcome. Try to limit the number of features for each goal to
three, but do not state more than five. Refrain from detailing the features, and focus on the product
capabilities that are necessary to meet the goal. Your product roadmap should be a high-level plan. The
details should be covered in the product backlog including epics and user stories.
The GO PRODUCT ROADMAP CHART

1st Quarter 2nd Quarter 3rd Quarter 4th Quarter

Version 4
Version 1 Version 2 Version 3

Acquisitions: Free Activation: Focus Retention Acquisitions: 


app, limited in on in-app New Segment
app purchases purchases
Basic game Purchase Dance New characters Street dance
functionality Moves and floors elements
Multiplayer Create new Enhanced visual Dance
FB Integration Dances design competition
Downloads, top Activations, Daily active Downloads
10 dance app downloads players - session
length
CREATING A PRODUCT VISION
Working on a product without a decent product vision resembles going into the street with
eyes closed. To advance a product (or life) direction helps keep things going and makes
actions meaningful. On the other hand, a leader has the responsibility for leading and guiding
others as well. PO's and managers need to keep business plans and customer requests in
mind while motivating everyone to work towards a common goal. Without direction, a team
can’t follow.
 PRODUCT VISION

When we discuss Vision - we have in mind the long term plan for the product. These are plans that are far
away and have not materialized yet. These are far away goals but none the less prove your business
ambitions and the future problem solving aspect of it. The vision is usually a two to five years time or even
more - depending on which product you are making for which industry.

So what? Isn’t this just a bunch of nonsense with no immediate impact?

Not really. Using a vision, the team can define the product goals, work out a strategy on how to reach
those goals, devise strategies and tactics and break them down within your product roadmap we
discussed earlier. Google’s vision statement is

“…to organize the world’s information and make

it universally accessible and useful”
 PRODUCT VISION

To look at it in a very easy way. You are a tour guide and you are hiking across the mountains. With your
guide group, your vision is to take them to see beautiful mountaintops, waterfalls and maybe even catch
some wildlife here and there. Without this vision, your tour guide group would be lost in their direction.

Vision should be a basis that guides decisions and helps prioritize features or tasks. Does this feature/
element/add-on contribute to the goal? If not, channel energy into activities that truly matter. 

Motivation also plays an important role here: remind the team at times of the direction so they understand
how their roles and daily activities contribute to the bigger picture. This helps them focus more on the
work that really makes a difference (in terms of product development).Some tasks might not seem fancy to
everyone but predicate customer happiness and a successful product.

We can explore a number of ways to creating a product vision.

First actually sit down and brainstorm on what problems or pains customers face and how the product
solves them, or what the product should achieve. Though some might find it obvious, it poses more
challenges than expected.Who should take part in the process? The complex task of vision creation
requires teamwork.

Invite teammates or other stakeholders who can contribute to the bigger picture by providing professional
knowledge, passion or visionary skills. Developers, designers, researchers, business or marketing people
could all fit there.But make sure to lead the creation flow and push the team to come to a final
understanding.
 PRODUCT VISION

Who is the target audience?

Which customer needs can the product satisfy?

Which product attributes determine the satisfaction of those needs?

Who is competing and how do they perform? (internal, external competitors)

What timeframe and product development budget determine the project?

After gathering a team of people in mind, work on the visionary statements and lead a workshop on the
topic.Form smaller groups where people can discuss and brainstorm on different questions. At the end of
the first session, each team should come up with a list of agreed upon and shareable ideas or answers.
After every team has presented their ideas, put the ideas up to vote so to select only the best ideas.

Use different methods and games to utilize the team’s abstract thinking – always keep track of the
progress and make everyone involved.

Target group: Define the target audience whose needs the product will satisfy.

Needs: What do these customers need? What solvable pains and challenges do they face?

Product: Define the product, generic attributes or features that can contribute to customer happiness.

Business goals: Have a clear picture how the product will benefit the company and what the business
goals and aspirations led to its creation.

PRODUCT VISION
 PRODUCT VISION

When aiming for something short and catchy, use Geoffry Moore’s product vision template as well. The
basic formula runs as follows:

For [target customer],

Who [customer need to be solved],

The [product name]

Is a [product category]

That [benefits, unique selling points].

Unlike [competitor product],

Our product [main difference].

 With this tool, grab the essence and the uniqueness of the product while defining the aims. This method
can work well in an agile environment as well.

PRODUCT VISION
 PRODUCT VISION

A vision doesn’t have to turn into a 20-page bible or a shiny poster glued to the wall.  Make statements
convincing and effective.The father of visions, Roman Pichler, calls the ideal product vision:

Clear & stable: Every participant should find it easy to understand, so avoid empty phrases that don’t say
anything (aka bullshit).

Broad & engaging: It should depict a higher picture that everyone can relate to and that inspires people to
give their best to make it happen.

Short & sweet: It needs get straight to the point.

Additionally, make it:

Achievable: Although a vision should be a futuristic idea of what the product might become, set a goal
that can be actually met.

Insightful: Craft the idea based on users’ needs and motives and define the main reason behind the
product’s existence.

PRODUCT VISION
 PRODUCT VISION

Finally, present the product vision to everyone involved in the development. Stakeholders must know
the direction they are heading so they can maintain confidence in their daily tasks and decisions.Share the
vision in any form – presentations, boards, posters, one-on-one meetings, etc.Transmit the message so
everybody understands it and can connect to and be honest about it.

Encourage questions and present use cases: bring examples how vision affects business strategies or
lower level decisions.Speak the language of the product vision’s audience and show them how they can
contribute to the betterment of the product.

RELEASE MANAGEMENT
 Release management

The Product Owner as we discussed before is responsible for the Product Backlog but also ultimately
responsible on what you deliver to the customers. You’ll need to plan this and also come up with a strategy
on how to release what, when and how. Let’s take a look at a few things to keep in mind as mentioned by
Robbin Schuurman from “The Home of Scrum”:

1. Consider your audience

Your target audience should drive all of your decisions. Continous delivery of value is obviously one of the
cornerstones in Agile. Continuous Delivery is becoming very popular and a lot of people want to be able to
do a new deployment of software practically every minute. Of course it is very helpful to be able to release
with little effort, with the push of a button. Wether or not you will actually use it, depends greatly on the
context. In some contexts (like Amazon's), releasing multiple times a minute seems to have a lot of value.
In other contexts, when working on HR- or payroll-systems for example, a release once a month might be
enough (at least, that was back in the days when I developed such products).

2. Create one releasable increment per Sprint

In many organizations, teams are working very hard on a lot of different things in a Sprint, this often results
in the team having 100% of the work, 80% done. Bottomline, this means that a lot of work has been done,
but no value for customers and users has been delivered, since it's not finished, it's not 'Done'! So help the
Development Team by offering focus, with a Sprint Goal for example. Support the Development Team to
deliver a Done Product Increment, as early as possible in the Sprint, which is helpful, since you will at least
end up with one Increment that could be released if you'd want to.
 Release management

3. Get ownership of the release process



Get ownership over the release process. Or better said: Support the Development Team in getting
ownership over the release process! In many organizations, doing releases (to production) is something
that is 'owned' by a department such as Release Management or Release Coordinators. When the
Development Team doesn't have ownership over the release process, it is often more difficult to do a
release and it often costs you as a Product Owner valuable time. What I've experienced to be very helpful
in the past, is to provide the Development Team with ownership over the release process. This is
something nor you, nor the Development Team can often decide by yourselves. So what you can do as a
Product Owner, is to create transparency about this topic during the Sprint Review for example. When
your stakeholders are asking you: "How can we become faster?" or "How can we deliver more value?".
Then help yourself and the Development Team, by raising awareness about the release process

4. Only release work that is Done

In many organizations, a lot of teams are releasing 'undone work'. This 'undone work' is work that is
released to production, but which isn't delivered conform the Definition of Done. This creates technical
debt, which costs you a lot of time and a lot of money to fix. It will cost you valuable time which you can't
spend on delivering value for customers and users! So respect the Definition of Done!