The document provides an overview of agile project management principles and methods. It discusses the agile mindset of valuing individuals, interactions, working software, and responding to change. The Scrum framework is introduced, including roles like the product owner, development team, and Scrum master. A case study walks through creating a product vision, prioritizing a backlog, and estimating stories.

1. Intro to Agile Project Management
Catalina Movileanu (@catalinamo)

2. Agenda
• Part 1: Set the stage
• Part 2: Agile Mindset and Methods – short overview
• Part 3: Scrum Framework – short overview
• Part 4: Case study – part 1
• Part 5: Case study – part 2
• Create user stories
• Prioritize the backlog/high level estimation
• Estimate user stories

3. Part 1
Set the stage
Work in pairs
Tell each other
(1) what did you get from the first part of the
workshop
(2) what are your expectations for today

4. Part 2
Agile Project Management

5. What is Agile?
• Agile is a way of thinking
(mindset/philosophy)
NOT a
• Process
• Framework
• Tool
• Agile way of thinking can be
manifested through many
different practices.
Many
Practices
12
Principles
4 Values
Agile
Mindset

6. The Agile Manifesto (4 Values)
• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

7. Agile 12 principles
• Satisfy customer with great
products
• Welcome change
• Deliver frequently
• Work with business
• Motivate people
• Face-to-face communication
• Measure work done
• Maintain sustainable pace
• Maintain design
• Keep it simple
• Team creates the best
requirements and design
• Reflect and adjust

8. Agile Principles 1/12
Our highest priority is to satisfy the customer through early and continuous
delivery of valuable software.
Satisfy customer with
great software

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

10. Agile Principles 3/12
Deliver working software frequently, from a couple of weeks to a couple of
months, with a preference to the shorter timescale.
Deliver frequently

11. Agile Principles 4/12
Business people and developers must work
together daily throughout the project.
Work with business

12. Agile Principles 5/12
Build projects around motivated individuals. Give them the environment
and support they need, and trust them to get the job done.
Motivate people

13. Agile Principles 6/12
The most efficient and effective method of conveying information to and
within a development team is face-to-face conversation.
Face-to-face
communication

14. Agile Principles 7/12
Working software is the primary measure of progress.
Measure software
done

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

16. Agile Principles 9/12
Continuous attention to technical excellence
and good design enhances agility.
Maintain design

17. Agile Principles 10/12
Simplicity--the art of maximizing the amount
of work not done--is essential.
Keep it simple

18. Agile Principles 11/12
The best architectures, requirements, and designs
emerge from self-organizing teams.
Team creates
architecture

19. Agile Principles 12/12
At regular intervals, the team reflects on how to become more effective,
then tunes and adjusts its behaviour accordingly.
Reflect and adjust

20. Agile Flavors
Scrum - Project Management Framework
XP - Focused on Engineering Practices
Lean and Kanban - Limiting work in progress & optimizing flow
DSDM - Explicit view of teams at the boarder stakeholder view
FDD - Focused on feature delivery
Crystal - Situationally Specific Solutions

21. Unifying themes of Agile Methods
• Emerging scope
• Timeboxed development
Cost Time
Scope Cost Time
Scope
Variable
Fixed
100%
must have Must
have
Should have
Could have
Traditional Management
Constraints
Agile
Constraints

23. Feasibility
Assessing value
• NVP
• IRR
• ROI
Project visioning
• Design the product box
Business Case

24. Initiation
Project chartering
• W5H (What, Why, Who, Where, and How) attributes
Aligning stakeholders expectations
• Wireframes
• Personas
• User story /backlog
• As a <Role>, I want <Functionality>, so that <Business Benefit>
• Story map/product roadmap
High level estimates
• customer value prioritization
• risk-adjusted backlog

25. Planning
• Backlog and product roadmap
• Plan releases
• Release planning
• Slicing stories
• Story estimation using planning poker (points, T-shirt size, jelly beans, etc)
• Build a release plan
• Iteration/Sprint planning
• Sprint backlog

26. Delivering Value
• Task/Kanban boards
• WIP limits
• Incremental delivery

27. Incremental vs. Iterative

28. Confirming Value
• Prototypes
• Simulations
• Demonstrations
IKIWISI - I know it when I’ll see it
Iteration review meeting

29. Tracking and reporting value
• earned value management for agile
projects
• SPI = completed features/planned
features
• CPI=earned value/actual costs
• cumulative flows diagrams (CFDs)
• risk burn down graphs
• task/kanban boards
• velocity

30. Part 3
Scrum Project Management Framework

31. What is SCRUM?
• A set of practices, roles, events, artifacts
• Transparency
• Inspection
• Adaptation
Definition from rugby football:
“a scrum is a way to restart the game
after an interruption, where the forwards
of each side come together in a tight
formation and struggle to gain possession
of the ball when it is tossed in among
them”

32. Scrum teams

33. Development Team
• Empowered to manage its own
work
• Self-organizing and cross-
functional.
• 5-10 members
• Deliver potentially releasable
increment of “done” product at
the end of each sprint.

34. Product Owner
• Responsible for maximizing the
value of the products
• Manages the product backlog
(including its prioritization,
accuracy, shared understanding,
value and visibility).

35. Scrum Master
• Responsible for ensuring that Scrum
is understood and used
• Servant leader to the development
team
• Scrum coach
• Removing impediments
• Facilitate meetings
• Assist the product owner

36. Scrum events
• Sprints
• Sprint planning meeting
• Daily Scrum - 15-minute timeboxed daily
meeting
• Sprint Review
• Sprint Retrospective

37. Artifacts
• Product backlog
• Sprint backlog
• Definition of done
• Burn down charts

38. Part 4
Case study – Oversight Steering Committee Meeting Tool

39. Oversight Steering Committee Meeting Tool
Part 1 (feasibility)
• Create a vision (elevator) statement
• Design the product box
Part 2 (initiating and planning)
• Create backlog – min 7 stories (10 min)
• Prioritize backlog (MOSCOW) (7 min)
• Estimate backlog stories (Fibonacci) (10 min)

40. Elevator statement

41. Design the Box
Front of the box
• Product name
• Logo/graphic
• 3-4 key selling points or objectives
Back of the Box
• Product description
• Features list
Think of your project as a product you have to sell, using limited space on front/back of the packaging box.
What would you say?

42. Part 5: Case study – part 2
• Create backlog
• Prioritize the backlog/high level estimation
• Estimate user stories

43. Create product backlog
• A product backlog contains descriptions of the functionality (user stories) desired in an
end product.
User stories are short, simple description of a feature told from the perspective of the
person who desires the new capability, usually a user or customer of the system.
• As a <type of user>, I want <some goal> so that <some reason>.

44. Twitter case study

45. Define backlog – 10 mins
• Write at least 7 user stories for your product

46. Prioritize backlog – MoSCoW
Time – 10 min
• M - Must have: Describes a requirement that must be satisfied in the final solution for the solution to be
considered a success.
• S - Should have: Represents a high-priority item that should be included in the solution if it is possible.
This is often a critical requirement but one which can be satisfied in other ways if strictly necessary.
• C - Could have: Describes a requirement which is considered desirable but not necessary. This will be
included if time and resources permit.
• W - Would have/WON'T: Represents a requirement that stakeholders have agreed will not be
implemented in a given release, but may be considered for the future. (note: occasionally the word "Would" is
substituted for "Won't" to give a clearer understanding of this choice)

47. Estimate backlog stories (Fibonacci) – 10 min

48. Feedback