MGMT 642: Agile Project Management

MGMT 642: Agile Project Management

Week 4
Outline
• Agile Life-cycle
• Planning at a Distance
• Envisioning
• Agile Scope
• Requirements
• Assignments

3 2023-08-13
Agile Life-cycle
Agile Project Life-cycle

Envisioning
Release plan
Product backlog
Plan iteration

Iteration
1 to 4
weeks Develop
Deliver Iteration review Stand-up
product
increments and retrospective meetings
increment 24
hours

Artifact
1

updates

Releases

5 2023-08-13
Planning at a Distance
Planning at a Distance
• Levels of Planning
• Implementing the 5 Levels of Agile Planning.pdf

From: Implementing the 5 Levels of Agile Planning, Raman Technologies, Inc.

7 2023-08-13
Envisioning
Envisioning in Agile Project Life-cycle

9 2023-08-13
Product Vision Board, Product Box
Target group Needs Product Business goals
• Who will the product • What problems are • What are the key • What are the high-
benefit? being addressed? features of the priority business
• Who are the • What benefits will be product? goals?
customers and users? provided?

Side Front Side Back

Impacts Impacts
Value of the product
Supporting Supporting
What’s In It For Me Features and capabilities
details details
(WIIFM)?
Costs Costs

10 2023-08-13
Product Roadmap

11 2023-08-13
Project Selection and Design
• Characteristics of Good Agile Projects
• Deliver a quality product quickly, but not all at once.
• You expect requirements to change or evolve.
• Organization is willing to free up team members.
• The product can deliver business value incrementally.
• Common risks of Agile Projects
• Overly ambitious schedule.
• Not enough decision makers.
• Remember the PPM model?

12 2023-08-13
Scoping the project
• Product Data Sheet (PDS)
• Project description
• Project objective
• Timeline
• Cost estimates
• Constraints
• Types of constraints include environmental, safety, economic, technical, political, project
schedule, team or product development
• Prioritization
• Due to the constraints, you'll need to prioritize between Scope, Schedule, People, Other
Resources, Quality.

13 2023-08-13
Designing your structure
• The Envisioning of the project will need • Features can be grouped by
to include high-level planning for the • Business Priority
whole project so add a few more days. • Available technicians
• Sprint is usually 1-4 weeks. • Available resources
• Business area
• As a starter, plan the first sprint as a
sprint 0. • Size Estimates
• T-shirt sizing at this point.
• Priority
• Build the highest priority features first.
• MoSCoW, Kano, RICE, etc.
• Focus
• Many teams work best with short and
focused sprints.
14 2023-08-13
Deriving your risk management approach
• If the team is good with Agile, try to work on the most difficult
features in the early sprints.
• If the team is new to Agile, try to work on the easy features in the
early sprints.

15 2023-08-13
Agile Project Charter
• Agile project charter is supposed to be much shorter than traditional project
charter.
• It usually needs to answer the W5H questions:
• Who will be engaged? – Covered in the project governance section
• What is this project about? – Covered in the project vision section
• Where will it occur? When will it start and end? – Covered in the timeline section
• Why is it being undertaken? – Covered in the project vision section
• How will it be undertaken? – Covered in the roadmap.
• Project Vision
• Vision: Why are we doing the project?
• Mission: What (deliverables) will be done in the project?
• Success Criteria: The expected results

16 2023-08-13
At the end of Envision stage, you should have:
• Product Vision Board • Example Team Norms
• Actively listen to what others are saying.
• Product Box • Attack the problem not the person.
• Product Roadmap • Seek to understand first.
• Only focus on "This" sprint and feature.
• Agile Project charter • If you see a problem, say something and make suggestions for
resolution.
• Team collaboration tools • Actively participate in the daily meetings - Be engaged.
• Track and report status • Solve conflict with the other person when possible. If not
• Facilitate joint feature development achievable, BOTH parties must come forward for help from
management.
• Push information out to team members • Email is a "Low-touch" communication vehicle and should not
be used to solve problems.
• Team norms • Don't respond to text messages during meetings - Provide
• Determine where team will be located, and how your full attention to the matter at hand.
they will work together. • Be respectful of one another.
• Have the best interest of the project as your first priority.
• Share and respect the roles and responsibilities of each team
member.

17 2023-08-13
Agile Scope
Impact Mapping
Decrease the
Why booking time by
50%

Who Customer Customer care

Immediate
How Easily access to the
booking page
Make the
payment easily
response to
customer
questions

“Book” button Chatting tool

Payment via
What on the home
PayPal on booking
page page
19 2023-08-13
Project Management Institute. A Guide to the Project Management Body of Knowledge (PMBOK® Guide) - Version 6
Product Backlog
• As described in the Scrum Guide, the
Product Backlog is an ordered list of
everything that is known to be needed
in the product.
• It is the single source of requirements
for any changes to be made to the
product.
• The Product Owner is responsible for
the Product Backlog, including its
content, availability, and ordering.
• Refer to the Agile Templates.xlsx

20 2023-08-13
Release Planning
• Iteration planned with
targeted release dates.
• May look similar to Gantt
chart
• In agile, a project consists of
multiple iterations.
• Each iteration should be time-
boxed.
• Each iteration’s duration
should be consistent (1-4
weeks).
• Agile Templates.xlsx
21 2023-08-13
Planning the release schedule
• There is
1) Product backlog - Not committed and not locked.
2) Release backlog - Not locked but if you want to use it, you're going towards traditional
project management.
3) Sprint backlog - Committed and locked.
• Release Backlog • Rough Order of Value (ROVe)
• It's a compromise with product owner. • Release Team delivers the highest value
• Organization has some control over product.
deliverables; therefore, you need to be • Create a ROV from epic.
careful if you want to use it. • ROV release date is NOT about what
• Release backlog is not a way for Product features will be delivered on the date but
Owner to step away from the team. rather what value will be delivered.
• Power of agile = Flexibility and frequent
changes
22 2023-08-13
Delivering without scope
• Scope = What + How
• In Traditional Projects
• Iron Triangle
• If Scope increases, Budget and Schedule
need to.

• In Agile Projects
• Scope is variable.
• Schedule and cost are defined at start.
• Sponsor tells you how long is the project and how much he is willing to pay for it - Schedule
and Budget are constant.
• It's up to the Product Owner to fill up the scope based on the priority.
• Flipped triangle (aka Vase) with filling-up the scope as much as possible.
• And Quality is baked into the scope.
23 2023-08-13
Inviting the right groups
• ScrumMaster • Parking Lot
• Sets up activities. • Right after the stand-up.
• Ensures key players are involved. • Go over any other matters.
• Set standards early in agile projects
• Product Demo
• Activities != Open forum
• Product Owner = Talker
• Should divide the group into Sitters and Talkers.
• Developers = Sitters (with limited
• Keeps project manager from hijacking meeting. contributions); Only time developers talk is
• Daily Standup when a question is asked.
• Developers = Talkers
• Product Owner, ScrumMaster, Project Manager
= Sitters

24 2023-08-13
Requirements
Product Backlog
• As described in the Scrum Guide, the
Product Backlog is an ordered list of
everything that is known to be needed
in the product.
• It is the single source of requirements
for any changes to be made to the
product.
• The Product Owner is responsible for
the Product Backlog, including its
content, availability, and ordering.
• Refer to the Agile Templates.xlsx

26 2023-08-13
Theme, Epics, User Stories, Tasks
Category Definition Description
Theme A group of related user stories • Used for release planning purposes.
• Stories can be grouped using the user story mapping
technique.
Epic A large user story • An epic is too large for one iteration, so it will eventually
be sliced into multiple user stories.
• This may be done by separating it into functional parts or
technical requirements.
User story A brief description of deliverable • Usually explains the type of user, what they want, and
value for a specific user why.
Task The work required to complete • The team identifies what task or tasks are required to
the user story complete the user story.

27 2023-08-13
Theme, Epics, Feature, User Stories, Tasks
• Epics are simply a collection of related User Stories, whereas Themes are broad
areas of focus with an associated business value.
• Feature can be a level in between Epic and User Story.

28 2023-08-13

Exploring Scrum, Dan Rawsthorne and Doug Shimp, 2011

Epic
• An Item that is 'too big' to be done all at once and, therefore, must be
decomposed into Stories.
• Reasons a Backlog Item May Be an Epic (from “Exploring Scrum: The
Fundamentals by Dan Rawsthorne and Doug Shimp):
• Since this Epic is actually a User Story, it will take between 10 and 40 Stories to
be able to deliver a minimal releasable version of it.

29 2023-08-13
Epic Continued
Reasons a Backlog Item May Be an Epic (CURB)
Complex The item might be too complex to be understood well enough to be agreed to.
Unknown Maybe nobody on the Team knows enough about the Item to even make a guess whether or not
it can be agreed to.
Risky There are too many unknowns; it is too risk to agree to the item without further investigation or
a mitigation strategy.
Big The item could just be too big to do in one Sprint, even though it is well understood.

• Examples:
• We want the system to be able to manage the pilots' schedules.
• We're going to need to train all our users on this new release.
• As a <tourist>, I want to <fly to Catalina for the weekend>.
• I need you to translate the website to Spanish, because I'm planning to do a lot of marketing of Catlina
Air in Mexico.

30 2023-08-13
2 Reasons for an Epic’s Agreement
1. To hold things that are inherited by all the
Stories extracted from (or belonging to) the
Epic.
• An Agreement for an Epic contains things that are
inherited by all the internal Stories.
• This is particularly useful if one wants to have a list of
SMEs for the Epic, or for documenting simplifying
assumptions that apply to all the Stories.
2. To hold requirements at the Epic (Capability)
level that will need to be satisfied before the
Capability is considered Done, or Releasable.
• About Doneness for the Epic itself, and could contain
requirements for internationalization, usability
testing, performance testing, and the like.
Exploring Scrum, Dan Rawsthorne and Doug Shimp, 2011

31 2023-08-13
Decomposing Epic into Stories

32 2023-08-13
Exploring Scrum, Dan Rawsthorne and Doug Shimp, 2011
User Story
• The most important unit of work that a Team does is the Story.
• The Story is a small unit of work (Item) that the Team does 'all at once'
and is used to provide small units of value.
• An Item that is small enough that the Team could actually do it all at
once (in a single Sprint).
• The INVEST Criteria for 'Good' Stories (from “Exploring Scrum: The
Fundamentals by Dan Rawsthorne and Doug Shimp):

33 2023-08-13
User Story Continued
The INVEST Criteria for ‘Good’ Stories (INVEST)

Independent • Stories should be internally independent during their execution; the success of one Story should not
depend on the success of another being done at the same time.
Negotiable • Stories are the negotiation units in Scrum; It is Stories that are agreed to in Planning and are delivered;
and the Team negotiates actual content of Stories during development.
Valuable • Stories are, by definition, units of value that are requested by Stakeholders or Team Members.
• The value can be external or internal – for Stakeholders or the Team.
Estimable • The Team needs to be able to agree to the Story, which implies that the Story’s effort could be estimated.
• However, some Stories are ambiguous and must be time-boxed
Small • Stories should be small enough that there is little confusion about what they mean, and so they can be
completed relatively quickly.
• Recommend a single focus per Story.
Testable • Stories should be testable; more precisely, each Story needs to be verifiable, so that the Team can
determine when it is Done.
• Doneness takes different forms for different Stories.

34 2023-08-13
User Story Continued
• Developing a user story is an opportunity to engage the Product
Owner and/or stakeholders.
• Product Owner to rank/prioritize the user stories based on expected
value to the business/customer.
• Based on the description of a user story, the team will provide an
estimate.

35 2023-08-13
User Story Continued
• A user story will look something like:
• “As a (role), I want to do (feature) so that I can do (reason/benefit).”
• “As a <passenger>, I want to <be able to select my seat online>, so that <I don't have to do it
at the airport>.” – A functional Story
• “Get a list of available Flights from CUTLASS.” – An Architecturally Significant Story because it
causes the Team to decide how to interface with CUTLASS.
• “Go talk to the pilots and find out what they think about pilot compensation.” – An Analysis
Story that should be time-boxed.
• “Review the suggestions the pilots have submitted to see if there's anything interesting
there.” – Another Analysis Story that needs to be time-boxed.
• “I need somebody to spend an afternoon with the pilots, to explain to them how the pilot
compensation page works.” – Yet another non-functional, time-boxed, Story, more of a 'train
the users' Story.

36 2023-08-13
Story’s Agreement
• General Agreements:
• Agreements about who the SMEs are for this Story, who the Story's
Coordinator will be, simplifying assumptions that refine the scope of
the Story, discussion of what is explicitly out of scope, and so on.
• Acceptance Criteria:
• How the Team Members will verify that they have produced the
Story's Value.
• Typically this is an informal description of the Black Box test[s] that
will pass and the list of additional artifacts (such as documentation
and training materials) that need to be developed along with the
code.
• A Story is said to be well-defined once its Acceptance Criteria are
know.
• Definition of Done:
• What the Team will do in order to mitigate Technical Debt; these are
usually procedural verifications or reviews that will take place.
• The Doneness Definition is often common across Stories that are of
the same Storyotype.

37 2023-08-13
Exploring Scrum, Dan Rawsthorne and Doug Shimp, 2011
Iterating and Releasing
Agile Project Life-cycle

Envisioning
Release plan
Product backlog
Plan iteration

Iteration
1 to 4
weeks Develop
Deliver Iteration review Stand-up
product
increments and retrospective meetings
increment 24
hours

Artifact
1

updates

Releases

39 2023-08-13
Iteration Planning
• In Sprint Planning the Product Owner works with the Team to negotiate what
Backlog Items the Team will agree to do in the Sprint in order to support the
Release Goals and Strategy.
• Each of these Items has an agreed-upon Definition of Done, and collectively these
Items are called the Team's Sprint Backlog.
• It is the ScrumMaster's responsibility to assure that the Team agrees to a realistic
amount of work, and the Product Owner does not unduly influence this
agreement.
• After agreeing to the Items the Team can do, the Team and the Product Owner
jointly agree to a single Sprint Goal that defines Success for the Sprint, and the
Product Owner advertises this Sprint Goal to the Stakeholders.
• The team might have to try out different approaches, so their plans are likely to
have a high likelihood of changes.
40 2023-08-13
Iteration Planning Activities
• Time-boxed for 2-4 hours.
• Iteration Planning Meeting Part 1
• Develop an iteration goal.
• Product Owner prioritizes the stories and answers questions regarding acceptance criteria.
• Or better yet, the stories are already prioritized prior to this meeting.
• Team will provide more detailed estimates and together decide which stories to do in the
upcoming iteration based on the capacity.
• Iteration Planning Meeting Part 2
• The team without Product Owner present, will break the stories into tasks.
• Task:
• All the activities needed in order to complete the Story.
• They are estimated in ideal time, which is how long a task will take without interruptions or impediments.

41 2023-08-13
Daily Planning Activities
• The Daily Scrum (Stand-up)
• 3 questions:
• 1. What have you done since the last Daily Scrum?
• 2. What are you going to do until the next Daily Scrum?
• 3. What impediments are standing in your way?
• Time-boxed for about 15 minutes.
• Other Discussion
• Any other discussions needed to resolve the impediments can happen after
this meeting for 15 minutes with the people that are needed.

42 2023-08-13
Iteration Review Activities
• Review/Demo is a meeting for the purpose of obtaining feedback and
adapting in order to add value.
• On the last day of the iteration, plan for 2-4 hours of review/demo to
the stakeholders.
• Reviews are formal sign-off/demo meetings to discuss what was
planned and what was accomplished.
• Completed stories are shown with the demo.
• Incomplete stories are moved to the backlog.
• Any valid feedback may become new/revised stories that move to the
backlog.
43 2023-08-13
Iteration Retrospective Activities
• Attendance is limited to the Cross-functional team members, Product
owner, and Team facilitator.
• On the last day of the iteration, plan for 2-4 hours of retrospective
after the Iteration Review.
• This is very similar to Lessons Learned.
• A retrospective is not about blame; it is a time for the team to learn
from previous work and make small improvements.
• This is not about the actual product deficiencies.
• Look at the qualitative (people’s feelings) and quantitative
(measurements) data.
• The team may end up with items to be added to the backlog.
44 2023-08-13
Activity: Developing Scope and
Requirements
Activity: Developing Scope and Requirements (10 mins)
• Assume that each item on the product roadmap is an epic.
• Decompose each epic to 2 user stories.
• Write them into a proper user story format.
• Only do the ones in the “Committed”.

46 2023-08-13
(Hide) Activity: Developing Scope and
Requirements (Potential answer)
• Course sign up / unsubscribe page:
• Sign up: As a student, I want a signup for the website, so that I can get access to the website.
• Unsubscribe: As a student, I want unsubscribe from the website, so that I no longer get an email from the website.
• Login / Logout
• Login: As a student, I want a login page, so that I can receive a personalized experience to users.
• Logout: As a student, I want a logout page, so that it can prevent unauthorized access to the system.
• Shopping cart:
• Add a course to a shopping cart: As a student, I want to add an agile course to my "Shopping cart", so that I can see a
list of courses to purchase.
• View a course to a shopping cart: As a student, I want to view the "Shopping cart", so that I can see a list of courses to
purchase.
• Payment method:
• Pay by Master Card: As a student, I want to select Master Card as a payment method, so that I can purchase courses
online using Master Card.
• Pay by AMEX: As a student, I want to select AMEX as a payment method, so that I can purchase courses online using
AMEX.

47 2023-08-13
Assignments
Homework Problem 4: Agile Scope
• Answer each question.
• Explain why and justify.
• Do NOT search the Internet.
• To be more consistent, please use below naming convention for your following
assignment:
• Homework4_[Last name]_[First letter of first name].pptx
• If file naming is not followed, there will be a grade deduction.
• Upload to the Homework section in Moodle.
• I will pick one group and the group will do 8-10 minute presentation at the start of the next
class.
• If you go under or over time, there will be a grade deduction.

49 2023-08-13
Homework Problem 4: Agile Scope Continued
• True or False • Rewrite the following requests so they are in
• Agile projects typically do more up-front the most common user story format:
planning than traditional projects. • 1. Code the system to support banner
• Agile projects typically do more overall planning advertisements from external advertisers to
than traditional projects. drive website revenue.
• If we create our plans at the last responsible • 2. System needs to allow reports to be run on
moment, they will not change. membership trends, including age and location
• Midcourse adjustments on agile projects are demographics.
not common. • 3. All financial transactions should be handled
• Knowledge work projects tend to have high via the SecureServe system.
rates of change.
• If the project diverges from the original plan,
this could be a sign our initial plan was flawed.

50 2023-08-13
Assignments due before next class
• Online forums
• One most interesting thing you learned about agile from today
• Weekly summary
• Review today’s lecture and summarize
• Homework Problem #4
• Project Case Study #2

51 2023-08-13
52 2023-08-13