Agenda

• Q&A

• Whats next in 2nd half of Term

• Test Review

• New Learning – Module 8 - Estimating

1
2nd half of term deliverables

ASSIGNMENT DUE
Term Project – Part 2 – assign today Tuesday, March 15
Case study 1 – assign next week Tuesday, March 22
Case study 2 Tuesday, March 29
Term Project – Part 3 Start – Tuesday, March 29
Test 2 REVIEW 2nd last class
Test 2 Last class

2
 Test 1 – COMBINED section
For any user story major rule is to be Independent. It means that there should be only
one verb-noun combination.

Independent, Negotiable, Valuable, Estimatable, Small, and Testable

As a marketing manager I want to track customer engagement so I can make decision about social media content.

a) There are two issues estimable and small this states as a marketing manager I want to find out different engagement matrix
is not specific so it is very broad.

b) It is not estimable so the development team cannot estimate the cost against the value and it is not small So, the story
has to be small so that development team can optimize the value they can find out the time and effort they have to put in
each activity so that is very broad.

Revise statement:
As a marketing manager I want to track net promoter score so that I can find out about customer satisfaction.
Test Review
 Agile Project
Management
Tools

This Photo by Unknown Author is licensed under CC BY

Agile Project Management Tools: Selection Criteria

There are many software solutions available for Agile project management.
For example for this course you are using Trello, which is a simplified
application.

The following list provides a summary of the criteria for selecting an

enterprise-level Agile project management tool.
1. Lifecycle Coverage
2. Team and Customer Collaboration

?
3. Visibility, Reporting and Analytics
4. Portfolio and Program Management Planning tools
5. Others (cost, scalability, ease of use, customization, security)
 1. Lifecycle Coverage

The software tool is reviewed to see if the below

Lifecycle Coverage items are included:
• Product, release and iteration planning and tracking
• Portfolio Management: Epic boards, Epic ranking
• Goal, themes
• Requirement Backlog
• Defect Repository
• Testing Management
• Road-maps

This Photo by Unknown Author is licensed

under CC BY-SA
2. Team and Customer
Collaboration

The software tool is reviewed to see if the

following Collaboration items are included:
• Communication portal for teams
• Team rooms, Planning rooms
• Email notifications
• Board views
• Customer Idea Management platform

This Photo by Unknown Author is licensed under CC BY-SA

3. Visibility, Reporting and Analytics

The software tool is reviewed to see if the following

Visibility, Reporting and Analytics items are included:
• Dashboards: Executive and team views
• Release forecasting
• Burn-down, burn-up, trend reporting
• Epic boards/Storyboards, work-in-process limits
• Roll-up reporting
• Customizable reports and dashboards
• Epic bubble charts, Hierarchy charts, release
mapping

This Photo by Unknown Author is licensed under CC BY-SA

4. Portfolio and Program Management Planning Tools

The software tool is reviewed to see if the

following Portfolio and Program Management
planning tools are included:
• Mapping and tracking of Portfolio-level items
such as release rollouts, progress and
organizational
• Release forecasting
• Cross-project team planning, tracking and
reporting

This Photo by Unknown Author is licensed under CC BY-NC-ND

 5. Other Criteria

Agile Project Management Tools – Other

Selection Criteria:
• Cost
• Scalability
• Ease of Use
• Customizable Workspaces, Process and
Terminology
• Security

This Photo by Unknown Author is licensed under CC BY-SA

 Agile Estimating:
Adaptive Versus
Predictive

This Photo by Unknown Author is licensed under CC BY

Estimating Techniques
 Predictive Plan Driven Terms

Think back to your first semester class

• What types of estimation did you study?

This Photo by Unknown Author is licensed under CC BY

 Predictive Plan Driven Terms

Think back to your first semester class

• What types of estimation did you study?

ate s To p p
E sti m D ow U
oi nt n om
3 P Analogous tt
Bo
Parametric
This Photo by Unknown
Author is licensed under
CC BY-SA-NC This Photo by Unknown Author is licensed under CC BY
 Estimation Process: Plan Driven vs Agile

Plan Driven Agile

Requirements, Cost , Schedule Estimated based on higher levels of
estimated up front uncertainty, less accurate

Estimates are seen as a contract with

the customer, and/or contract between Collaboration, partnership, transparency
Business Owner with customer

Estimated based on static and

Estimate based on a high-level, dynamic
well-defined model (may not be view. Likely to change and less accurate
realistic) This Photo by Unknown Author is licensed under CC BY

Changes are controlled Changes are encouraged

This Photo by Unknown Author is licensed under

CC BY-SA
Agile Requirements Decomposition

Want to allow customers to

Be able to order, , pay and recieve
Food with goal of increasing
Revenues and realizing efficiencies

Eg. Order Crypto / Pizza online

(high level requirement)

Pay with c.c.; Bitcoin

Browse menu
Select items on menu
(Detailed requirements)

Display menu

System asks ‘do you want want

17 What you ordered last time)
Decomposing Requirements

Exercise – we are building a Booking system for airlines.

Identify 1 Theme = be able to order a airline ticket

decompose the Theme into 2 Epics

and decompose the Epics into 1 or 2 User Stories
Decomposing Requirements

Theme Buy a Plane Ticket

Checkout Pay for Manage

Search
Epic/Feature Flight Profile (incl
Flights
points)

User Stories Search Select Pay Change

by City Seats Credit Card Address

Search Select Pay

by Data Request
Insurance Bitcoin
new Points
Search Card
By Price
 Code class library
New setup for testing
Acceptance test defined
Configure system
Design interface
Transformation matrix
Write code

Theme Epic/Feature
20
User Stories Tasks
 Agile Levels of Estimation
Project/Product Planning
Time: Long range
Estimation Accuracy: Low
Uncertainty: High
• Vision and High-level goals
• Define Epic and User Stories
• High-level estimates
• Done at start of project and
updates as lower level estimates
change
• Items may be defined or open-
ended
First 1- 2 weeks
We use an estimating
method called
Relative estimating –
Fibinocci or T-shirt
Release Planning
Time: Longer than Sprint
Estimation Accuracy: Medium
Uncertainty: Medium
• Estimate schedule for release,
may be subject to change
• Items defined to Epic-level at
minimum
Week
2
Sprint Planning
Time: 2-4 weeks
Estimation Accuracy High
Uncertainty: Low
• Include tasks (time-boxed) that
can be included in sprint
• Fixed schedule & Fixed scope
(items included)
• Uncertainties in Project and/or
Release Planning are resolved
Estimation
Agile estimation aims at reasonably predictable
estimates and does not strive for precision.

To quickly converge on an accurate estimate, Agile

recommends using non-linear scales. A commonly
used non-linear scale is the Fibonacci series, in which
the succeeding number is the sum of the previous two
numbers

.
 Agile projects is
RELATIVE based – NOT time

Waterfall / Plan driven estimating eg. Running from 401 and Yonge
Is TIME – based Street to eatons Center – how long will
It take you - 1 person says 95 min, 45 min
Eg. How long will it take you - TIME BASED IS NOT accurate and depends
To wire the house? The persons skill and knowledge
A – 3 days
To make objective estimates we use RELATIVE
called Fibinocci

There are 122 city block from

Yonge and 401 and Eaton centre

In software – 84 test case – does NOT depend

On the skill or knowlgge of the person
Doing the work
EXERCISE
Using Story Points

Product backlog item Estimate

Read a book

Critique the book – is it a good or bad book and why?

Write an article drawing on the core aspects of 5 religions

24
 ProjectTime-Boxing
Exercise: and Release-Levels of Estimation
• Project and Release-level planning and estimation is optional depending
on the project
• Highest Level of planning is Project-level, and Agile teams are not expected
to accurately estimate
• Level of Accuracy of Project-level estimates depends on factors including
 Nature and complexity of the project
 Level of uncertainty in project requirements
 Needs to have project schedule and cost estimates
• Level of Accuracy of Release – level planning is the intermediate level
between Project-level and Sprint level planning and is optional and may be
used to break large complex projects into releases
 Sprint Level of Estimation
Exercise: Time-Boxing
• Sprint level Planning and estimation is essential
• Project and Release planning and estimation is optional
depending on the project
• Lowest Level and most detailed is Sprint level, and Agile
teams are expected to accurately predict sprint capacity
• Prior to starting a Sprint, features to be included should be
known and understood well enough to accurately estimate
the level of effort needed to create the items
USEr STORY - As a customer I want to be able to see exactly where my pizza is location wise using GPS

Task (work) to deliver this user story – so it works!

1. Research GPS products

2. Determine budget to spend on GPS products
3. Purchase GPS
4. Place GPS in drivers car – cell phonr
Estimation:
Story Points,
Planning Poker

This Photo by Unknown Author is licensed under CC BY-SA

 Story Point
Exercise: Time-Boxing

• Metric commonly used for estimation in Agile projects

• Sizes the level of effort
• 120 city blocks to run (not time based)
• 2 level of relative effort to read a book

• Not directly tied to a specific time measure

• Relative measure of level of difficulty of one story versus
another
• Story point may have different meanings in different Agile
teams. Example: Story point could be per PP slide, per
page of a book
This Photo by Unknown Author is licensed under CC BY-SA
What is a Story Point
• The ‘bigness’ of a task – size, complexity, risk
• Uses relative deduction of ALL team members
• Story points are ‘deduced’ relatively
– building a login screen/function is a 2
– Building a search feature is a 5

Story Point

Size Complexity Uncertainty

‘how big is how hard is whats not
it? it? known?
30
Understanding Size and Complexity

Size 1 mile 1 mile

Complexity 1 13

31
Story Points: Frequently Asked Questions (FAQ)

Why not just use hours? (Clickable answesr?)

Hours can provide inaccurate estimates. Hours depend on person
doing it, and when they are doing it. Points are a more relevant
metric to measure completion of work.
Are there any cases where using hours can be justified?
A team without any experience will find it difficult to have a frame of
reference. These teams can start with one point being equal to a
person day of work. Once the team gains experience they can use
relative comparisons
What numbers are used?
There are many options, T shirt sizes (S,M,L XL) numbers
(1,2,3,5,,8,13,21..note each number is the sum of previous 2
numbers)
32
 Story Point Usage
Exercise: Time-Boxing

High-level
Tactical Sprint Project-level and
Product Backlog
Planning Release Planning
Grooming

• Voting technique • Team determine • High-level story

used to estimate velocity to point estimates
• Product Owner will determine how combined with
weigh the story many points/sprint velocity can develop
points against • More detailed project and release
business value and estimate estimates
rank the order

This Photo by Unknown Author is licensed under CC BY-SA

 Ready to Start with the End in Mind
Definition of Done

Definition of Done(DoD)
• A team's definition of done is an agreed-upon set of things that must be true before any product
backlog item is considered complete.
– what the team need to have accomplished for the story to exit the sprint?
– Can consider as a checklist

Code level Clean Kitchen

Capability is coded ?
Coded to standards ?
Comments are available in the code ?
Peer code review performed ?
Unit and Integration test 100% passed
Used test environment identical to
production environment
 Ready to Start with the End in Mind
Definition of Done
• User Story level (or backlog item) – "As a user, I am required to login before using the site,“

– user is logged in only when proper credentials are provided

– a "remember me" option is available
– user can request a password reminder
– user is locked out after three failed attempts

• Sprint level
– DoD of each single User story, included in the Sprint are met
– “to do’s” are completed
– All unit tests passed
– Product backlog updated
– Project deployed on the test environment identical to production platform
– Tests on devices/browsers listed in documentation passed
– Tests of backward compatibility passed
– The performance tests passed
– All bugs fixed
– Sprint marked as ready for the production deployment by the Product Owner
 Planning Poker: Steps
Exercise: Time-Boxing
1
/ 2 3
5
0 2
1. Present a story to the Team, discussing any questions 2 8
2. Each Member of the team chooses a card revealing their 1
3
0 ?
estimate
3. Everyone shows their cards
4. Team discusses why they voted differently focusing on the
outliers
5. The team then chooses cards again, repeating steps 2-5 until:
a. The estimates are within a chosen range or
b. The number of defined rounds are complete
c. Consensus is achieved

This Photo by Unknown Author is licensed under CC BY-SA

 Planning Poker
Exercise: Time-Boxing

Optional: 1
/ 2 3
5
You can use the website below for your Term Project: 0 2
2 8
1
3
0 ?

www.planningpoker.com
Velocity and Burn-
down Charts
 Velocity

• Agile estimates are based primarily on team

velocity
• Projecting velocity , monitoring actual velocity,
adjusting estimates as needed
• Velocity is:
o Measure of Agile Team throughput per
iteration
o Rate that a Team delivers value
o Number of estimated units (story points)
delivered in an iteration (sprint)
Team Velocity
• Velocity is the number of story points per sprint completed
• Accurately stated, it is measured in terms of the stabilized number of Story Points a
team can deliver per sprint of a given length, and with a given definition of Done.
• You calculate velocity to predict how much work to commit to in a sprint
• Velocity only works if you estimate your story points consistency
• Should not be used as a measure of comparison across teams
• Lean concept of Limiting Work to Capacity

Team A is working in 2-week sprints on work that it has estimated together.

Team A has been working together for several sprints, and consistently delivers between 18 and 23
points of working software every sprint.

We could reasonably expect Team A to deliver roughly 20 points per 2-week sprint, and so we
consider that to be the team’s velocity for planning purposes.

If there are eight 2-week sprints in a release, we can extrapolate that Team A has the capability to
deliver 160 points in a release.
 User stories Story points
Scrum Velocity Example US 1 21
US 2 13
US3 13
• Veloci US4
US5

41
Velocity Example
• For the 1st release the Team has completed, the team completed 60 story
points of work in 3 sprints
• Each Sprint is 2 weeks long

• Current release is 300 story points

1. Based on the previous Release, what is the velocity in STORY POINTS
1. per SPRINT?
2. per WEEK?
2. How many weeks will it take to have the Current release completed?

42
Velocity Example
• For the 1st release the Team has completed, the team completed 60
story points of work in 3 sprints
• Each Sprint is 2 weeks long

1. What is the velocity based on the previous release?

20 story points/Sprint
10 story points/Week
2. How many weeks will it take to have the Current release completed?
30 weeks 15 sprints

43
 Sprint Burndown Chart
Velocity is Key Metric

• A display of what work has been completed and what is left to complete
• one for each developer or work item
• updated every day
• (make best guess about hours/points completed each day)
 Burn-down Chart
Burn-down chart tracks progress of work completed against time allowed.
X-axis: Time frame
Y-axis: Amount of remaining work (person hours, or story points)

• Chart start outs with the total amount of

work, and slowly burns down to no work
• Useful for monitoring actual progress of work
done
• Story points provide a more reliable and
accurate measurement than hours
What does this remind you of from a Predictive or Plan Driven Project Metric?
 Burn-down Chart
Burn-down chart tracks progress of work completed against time allowed.
X-axis: Time frame
Y-axis: Amount of remaining work (person hours, or story points)

• Chart start outs with the total amount of

work, and slowly burns down to no work
• Useful for monitoring actual progress of work
done
• Story points provide a more reliable and
accurate measurement than hours
What does this remind you of from a Predictive or Plan Driven Project Metric?
Answer = EVM: Earned Value Measurement
Estimating
High Level Planning vs Sprint Planning

47
Estimating
High Level Planning vs Sprint Planning
Start of Agile Project Start of each Sprint
Product Backlog Planning Sprint Planning
High Level & Arbitrary Scale Detailed & Time Scale

48
Source = https://help.rallydev.com/sizing-and-estimates-overview
Sprint Planning Meeting
Sprint Forecast - Actionable Plan
Output - Sprint Planning Meeting
A Look at what makes up the Sprint forecast

User story is in STORY POINTS

 Assignment Part 2

• Lets review assignment Part 2

Extra
 Estimation: Two Extremes
• Two common extremes
• Right approach is somewhere in between
• Use the information you have, use it to make decisions
• Do not underestimate level of uncertainty

Lack of commitment

Not bothering to
spend anytime on Analysis Paralysis
estimates
Spending too much
time attempting to
provide detailed
estimates on
unreliable
information
Estimation: Situation Analysis in an Uncertain Environment

What
information
is unknown
What or uncertain?
What can I
information
reasonably
do I know for
assume?
sure?

Analyz
e
Communication Tools & Practices, Plan Driven vs Agile
Plan Driven Agile

Software Tools MS Project Version One, Rally , Jira

Project Oriented to define and manage Manage the flow of project
Management Role structure of project activities activities

Information Limit sharing of information to control Open, transparent,

distribution channels of communication information radiator

Focus Focus on controlling the project Focus on maximizing value

constraints (time-cost-scope)
Reporting PM updates status reports Team updates status of
individual work
R

Information Radiators enable fast flow of information….

• Flow of information is more open in Agile

• Information is rapidly changing and sharing needs to be efficient

• Information radiators are used to display project information in a highly visible method

• Everyone is aware of what team members are working on, and how the work relates to the
project objectives

What is a definition of Information Radiator?

What are examples of Information Radiator?
Information Radiator

• Large highly visible display of team information

• Visible by all
• Continuously updated as work is completed
• Information Radiator goals include:
• Creates an atmosphere of openness and
transparency
• Promotes partnership with those outside the
team
• Reduces burden on one individual gathering
information and creating status reports
Review the short video that shows the usage,
benefits, and how to measure the success of
Information Radiators
 INFORMATION RADIATOR - HIGHLY VISIBLE to ANYONE
PROJECT WHITEBOARD
The Power of a Whiteboard https://www.101ways.com/2009/03/09/the-power-of-a-whiteboard/

58
Another Whiteboard – with Burndown Chart
Another INFORMATION RADIATOR

59
 INFORMATION RADIATOR – KANBAN Board

• Kanban is a Japanese word meaning “Sign-Board”  shows the work items in each stage of the production process, as defined by the team – may be
called task board on exam

• Kanban employs a “Pull System” to move work through the development process, rather than planning their work in time-boxed iterations  Each time a
Kanban Team completes an item of work, it “triggers’ a pull to bring them the next item they will work on
R

What is the most efficient method of communication?

R

What does co-location mean?

R

In an Agile project, when might you change the

communication strategy? In other words, what situation
would you use more documentation than you may
otherwise, may use video, may change times of the
daily standup meeting?