Introduction to Scrum and How to Apply It with Asana, heavily based on Scrum Primer (http://scrumprimer.org/)

1. Scrum with Asana
an agile project management and software development process
James G. Kim
Strategic Planning Director of LiST Inc.
JGKim@LiSTInc.kr
April 17th, 2015

2. Agile Manifesto
2
In February 2001, seventeen software developers, including Kent Beck, Ward Cunningham, and Martin
Fowler, met at the Snowbird ski resort, and published the Manifesto for Agile Software Development:
We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:
• Individuals and Interactions over Processes and Tools
• Working Software over Comprehensive Documentation
• Customer Collaboration over Contract Negotiation
• Responding to Change over Following a Plan
That is, while there is value in the items on the right, we value the items on the left more.
Derived from AgileManifesto.org

3. Project Vision Drives the Features
3
Waterfall Agile
Contraints
Estimates
Features
Cost Schedule
Plan Driven
Features
Cost Schedule
Value - Vision
Driven
The Plan Creates
Cost/Schedule Estimates.
The Vision Creates
Feature Estimates.
Derived from Arrielle Mali’s slides

4. Pull Systems
4Derived from Arrielle Mali’s slides
CapacityInput
?
Push systems overwhelm capacity, creating turbulence, waste, and delay.
Input Capacity
Pull systems have a steady flow that provides predictability.

5. Agile Principles
5
The Agile Manifesto is based on 12 principles:
• Customer satisfaction by rapid delivery of useful software
• Welcome changing requirements, even late in development
• Working software is delivered frequently (weeks rather than months)
• Close, daily cooperation between business people and developers
• Projects are built around motivated individuals, who should be trusted
• Face-to-face conversation is the best form of communication (co-location)
• Working software is the principal measure of progress
• Sustainable development, able to maintain a constant pace
• Continuous attention to technical excellence and good design
• Simplicity — the art of maximizing the amount of work not done — is essential
• Self-organizing teams
• Regular adaptation to changing circumstance
Derived from AgileManifesto.org

6. “Rugby”Approach
6
The holistic or “rugby” approach has been defined, as the whole process is performed by
one cross-functional team across multiple overlapping phases, where the team “tries to
go the distance as a unit, passing the ball back and forth” in 1986 by Hirotaka Takeuchi
and Ikujiro Nonaka in The New New Product Development Game.
Derived from The New New Product Development Game

7. Moving the“Scrum”Downfield
7
From interviews with organization members from the CEO to young engineers, we learned that leading
companies show six characteristics in managing their new product development processes:
• Built-in Instability
• Self-organizing Project Teams
• Overlapping Development Phases
• “Multilearning”
• Subtle Control
• Organizational Transfer of Learning
These characteristics are like pieces of a jigsaw puzzle. Each element, by itself, does not bring about
speed and flexibility. But taken as a whole, the characteristics can produce a powerful new set of
dynamics that will make a difference.
Derived from The New New Product Development Game

8. Scrum Methodology
8Derived from The Scrum Primer
In the early 1990s, Ken Schwaber and Jeff Sutherland developed what would become “Scrum” at their
respective companies, and in 1995, they jointly presented a paper describing the Scrum methodology
at the Business Object Design and Implementation Workshop held as part of OOPSLA ’95.

9. Scrum Roles
9Derived from The Scrum Primer
In Scrum, there are three roles: Product Owner, Team (also called Development Team), and Scrum Master.
Together these are known as the Scrum Team.

10. Scrum Roles: Product Owner & Team
10
The Product Owner represents the stakeholders, and is the voice of the customer. He or
she is responsible for maximizing return on investment (ROI) by identifying product
features (typically user stories), translating these into a prioritized list (i.e., Product
Backlog), deciding which should be at the top of the list for the next Sprint, and
continually re-prioritizing and refining the list. The Scrum Team has one and only one
Product Owner, and while he or she may also be a member of the Team, this role
should not be combined with that of the Scrum Master.
Derived from The Scrum Primer
The Team (also called Development Team) is responsible for delivering potentially
shippable increments (PSIs) of product at the end of each Sprint (the Sprint Goal). The
Team in Scrum is “cross-functional” and it is “self-organizing” (self-managing), with a
very high degree of autonomy and accountability. The Team decides how many items
(from the Product Backlog) to build in a Sprint by adding them to the Sprint Backlog,
and how best to accomplish that goal. Since each member of the Team is just a team
member, the Team is not only cross-functional but also demonstrates multi-learning.

11. Scrum Roles: Scrum Master
11
The Scrum Master helps the product group learn and apply Scrum to achieve business
value. The Scrum Master does whatever is in their power to help the Team, Product
Owner, and organization be successful. The Scrum Master is not the manager of the
Team members, nor are they a project manager, team lead, or team representative.
Instead, the Scrum Master serves the Team; he or she helps to remove impediments,
protects the Team from outside interference, and helps the Team to adopt modern
development practices. He or she educates, coaches, and guides the Product Owner,
Team, and the rest of the organization in the skillful use of Scrum.
Derived from The Scrum Primer

12. Asana: Teamwork without Email
12
Asana is a Web-based solution for the effective collaboration of teams. Main user focus is to plan and
manage projects and tasks online without the use of email.
The Asana workflow for Scrum:
• Each team gets a “workspace” for each project,
• Workspaces contain ”projects” for lists, and
• Projects contain ”tasks” for items.
In each item, users can add notes, comments,
attachments, and tags.
Users can follow lists and items, and when the
state of a list or item changes, followers get
updates about the changes in the inboxes.

13. Product Backlog
13
The Product Backlog is a prioritized list of customer-centric features desired in the
product. It exists (and evolves) over the lifetime of the product.
Derived from The Scrum Primer
The Product Backlog includes a variety of items:
• New Customer Features
(e.g.,“enable all users to place book in shopping cart”)
• Major Engineering Improvement Goals
(e.g.,“rewrite the system from C++ to Java”)
• Improvement Goals
(e.g.,“speed up our tests”)
• Research Work
(e.g.,“investigate solutions for speeding up credit card validation”)
• Known Defects, if there are only a few problems
(A system with many defects usually has a separate defect tracking list.)
The Product Backlog Items (PBIs) are ordered by the Product Owner based on considerations like risk, business value,
dependencies, date needed, etc.
The Product Backlog exists (and evolves) over the lifetime of the product; it is the product roadmap
(Figure 2 and Figure 3). At any point, the Product Backlog is the single, definitive view of
“everything that could be done by the Team ever, in order of priority”. Only a single Product Backlog
exists for a product; this means the Product Owner is required to make prioritization decisions across
the entire spectrum, representing the interests of stakeholders (including the Team).
Figure 2. The Product Backlog
Figure 3. Visual Management: Product Backlog items on the wall
The Product Backlog includes a variety of items, primarily new customer features (“enable all users to
place book in shopping cart”), but also major engineering improvement goals (e.g., “rewrite the system
from C++ to Java”), improvement goals (e.g. “speed up our tests”), research work (“investigate
solutions for speeding up credit card validation”), and, possibly, known defects (“diagnose and fix the
order processing script errors”) if there are only a few problems. (A system with many defects usually
has a separate defect tracking system.)
Product Backlog items are articulated in any way that is clear and sustainable. Contrary to popular
misunderstanding, the Product Backlog does not contain “user stories”; it simply contains items. Those
items can be expressed as user stories, use cases, or any other requirements approach that the group
finds useful. But whatever the approach, most items should focus on delivering value to customers.
A good Product Backlog is DEEP…
6

14. Product Backlog: DEEP
14
A good Product Backlog is:
• Detailed appropriately:
The top priority items are more fine-grained and detailed than the lower priority items, since the
former will be worked on sooner than the later.
• Estimated:
The items for the current release need to have estimates, and furthermore should be considered for
re-estimation each Sprint as everyone learns and new information arises.
• Emergent:
In response to learning and variability, the Product Backlog is regularly refined. Each Sprint, items
may be added, removed, modified, split, and changed in priority.
• Prioritized:
The items at the top of the Product Backlog are prioritized or ordered in a 1-N order.
Derived from The Scrum Primer

15. Product Backlog in Asana
15

16. User Stories
16
Product Backlog Items are articulated in any way that is clear and sustainable. Items can
be expressed as User Stories, Use Cases, or any other requirements approach that the
group finds useful.
User Stories are written by or for business users or customers as a primary way to
influence the functionality of the system being developed. User Stories may also be
written by developers to express non-functional requirements (security, performance,
quality, etc.), though primarily it is the task of the Product Owner to ensure User Stories
are captured.
As a <role>, I want <goal/desire> (so that <benefit>).
As a purchaser, I want to search for generic equivalents of brand named items so that I can save money.
Derived from Wikipedia

17. User Stories: INVEST
17
INVEST Criteria for User Stories:
• Independent:
The User Story should be self-contained, in a way that there is no inherent dependency on another User Story.
• Negotiable:
User Stories, up until they are part of an iteration (i.e., Sprint), can always be changed and rewritten.
• Valuable:
A User Story must deliver value to the end user.
• Estimable:
You must always be able to estimate the size of a User Story.
• Small Sized:
User Stories should not be bigger than one Sprint.
• Testable:
The User Story or its related description must provide the necessary information to make test development possible.
Derived from Wikipedia

18. User Stories in Asana
18

19. Product Backlog Refinement
19
Product Backlog Refinement is the ongoing process of the whole Scrum Team’s refining
(or“grooming”) the Product Backlog to support future Sprints.
The Product Backlog Refinement takes no more than 10% of the capacity of the Team for
the Sprint. For example, in a two-week Sprint, perhaps one day is spent on refinement.
• Detailed Requirement Analysis
• Splitting Large Items into Smaller Ones
• Estimation of New Items
• Re-estimation of Existing Items
Derived from The Scrum Primer

20. Priorities based on Risk, Effort, and Value
20
Asking the following questions of the different items will start a conversation that will
start to determine priorities:
• Which items add the most value to the user (or customer)?
• Which items post the most business risk?
• Which items pose the most technical risk?
It’s helpful to rank items along the three questions using a scale.
• Fibonacci Scale: 1, 2, 3, 5, 8, …

21. Sprint Planning
21Derived from The Scrum Primer
Sprint Planning is a meeting to prepare for the Sprint, typically divided into two parts
(part one is “what” and part two is “how”). Each part is timeboxed to one hour per week
of Sprint.
• Sprint Planning Part One:
The Product Owner and Team review the high-priority items in the Product Backlog that the Product
Owner is interested in implementing in this Sprint. The Team and the Product Owner may also devise
the Sprint Goal, a summary statement of the Sprint objective.
• Sprint Planning Part Two:
The Team forecasts the amount of items they can complete
by the end of the Sprint, starting at the top of the Product
Backlog and working down the list in order. The Team
selects the first item on the Product Backlog and work their
way down until they are ‘full’. For each item, they create a
list of work which consists of either decomposed Product
Backlog items into tasks, or simply the Product Backlog
item. This list of work to be done during the Sprint is called
the Sprint Backlog that details the time it will take to do
that work.

22. Tracking Progress during the Sprint
22
this is the reality of product development. The important thing is that it shows the Team their
progress towards their goal, not in terms of how much time was spent in the past (an irrelevant fact in
terms of progress), but in terms of how much work remains in the future – what separates the Team from
their goal. If the burndown line is not tracking downwards towards completion near the end of the
Sprint, then the Team needs to adjust, such as to reduce the scope of the work or to find a way to
work more effectively while still maintaining a sustainable pace.
While the Sprint Burndown chart can be created and displayed using a spreadsheet, many Teams find it
is more effective to show it on paper on a wall in their workspace, with updates in pen; this “low-tech/
high-touch” solution is fast, simple, and often more visible than a computer chart.
Figure 6. Daily Updates of Work Remaining on the Sprint Backlog
this is the reality of product development. The important thing is that it shows the Team their
progress towards their goal, not in terms of how much time was spent in the past (an irrelevant fact in
terms of progress), but in terms of how much work remains in the future – what separates the Team from
their goal. If the burndown line is not tracking downwards towards completion near the end of the
Sprint, then the Team needs to adjust, such as to reduce the scope of the work or to find a way to
work more effectively while still maintaining a sustainable pace.
While the Sprint Burndown chart can be created and displayed using a spreadsheet, many Teams find it
is more effective to show it on paper on a wall in their workspace, with updates in pen; this “low-tech/
high-touch” solution is fast, simple, and often more visible than a computer chart.
Figure 6. Daily Updates of Work Remaining on the Sprint Backlog
Figure 7. Sprint Burndown Chart
12
Everyday, the Team members update their estimate of the effort remaining to complete
their current work in the Sprint Backlog. It is also common for someone to add up the
effort remaining for the Team as a whole, and plot it on the Sprint Burndown Chart.
Derived from The Scrum Primer

23. Sprint Backlog in Asana
23

24. Estimate of Effort in Asana
24

25. Daily Scrum
25
The Daily Scrum (or stand-up) is a short (15 minutes or less) meeting that happens every
workday at an appointed time. It is the Team’s opportunity to synchronize their work and
report to each other on obstacles.
• Before the Daily Scrum:
Each member makes sure that the personal ”Assigned to Me” list in the workspace in Asana is
properly reflecting the prioritization for the day and the Team’s involvement in the project.
• During the Daily Scrum:
One by one, each member of the Team reports three things to the other members of the Team:
1. What has been accomplished since the last meeting?
2. What will be done before the next meeting?
3. What obstacles are in the way?
There is little or no in-depth discussion during the Daily Scrum.
• After the Daily Scrum:
Each member updates the “Assigned to Me” list and any relevant lists in Asana.
Derived from The Scrum Primer

26. Scrum Board in Asana
26
Many Teams have a Sprint Backlog in the form of a wall-sized task board (often called a
Scrum Board) where tasks (written on Post-It Notes) migrate during the Sprint across
columns labeled“To Do,”“Work in Progress,”and“Done.”

27. Working with Gitflow Workflow
27
• When starting work on a Backlog Item by the Team:
- First, move the Backlog Item from the “To Do” Section to the “Work in Progress” Section in Asana.
- Second, start a new Feature or Hotfix with Git.
• After finishing work on a Backlog Item by the Team:
- First, move the Backlog Item from the “Work in Progress” Section to the “Done” Section in Asana.
- Second, finish up a new Feature or Hotfix with Git.
• After reviewing work on a Backlog Item by the Product Owner:
- Mark the Backlog Item completed in Asana.
• At the end of the Sprint:
- Make a release with Git.
The Gitflow Workflow is Vincent Driessen's strict branching
model designed around the project release (i.e., the end of
the Sprint).

28. Sprint Review
28
After the Sprint ends, there is the Sprint Review, where people review the Sprint.
• The Sprint Review is an inspect and adapt activity for the product.
• For a two-week Sprint it is a maximum length of two hours.
• Anyone present is free to ask questions and give input.
The review definitely includes using the actual live software that the Team built during
the Sprint, but if the focus of the review is only looking at the product rather than having
a conversation, there is an imbalance.
The“live software”portion of the Sprint Review is not a“presentation”the Team gives —
there is no slideware.
Derived from The Scrum Primer

29. Sprint Retrospective
29
The Sprint Retrospective, which follows the Review, involves inspect and adapt regarding
the process and environment. It’s an opportunity for the Team to discuss what’s working
and what’s not working, and agree on changes to try.
• Timeboxed to 45 minutes per week of Sprint.
• Team, Scrum Master, and Product Owner (optional) attend.
• Sometimes the Scrum Master can act as an effective facilitator.
• It’s important to ensure that every Retrospective focuses not only on problems, but
also on positives or strengths.
Derived from The Scrum Primer

30. Thank You.
30