Plan, make decisions, and demonstrate your learning so you can succeed.
Move quickly from decision-making to action and innovation. Companies using Agile Project Management principles to run projects allows organizations with an Agile mindset to respond quickly and effectively to the complexity and uncertainty that characterize today’s business needs.
Illustration of Agile Project Management
What is Agile Project Management?
Broadly defined, Agile Project Management is an iterative process that focuses on customer value first, team interaction over tasks, and adapting to current business reality rather than following a prescriptive plan. Agile Project Management is based on the same organizational practices and key principles found in the Agile Manifesto.
The diagram below displays the differences between agile and waterfall development processes. By delivering working, tested, deployable software on an incremental basis, agile development delivers increased value, visibility, and adaptability much earlier in the life cycle, significantly reducing project risk.
Agile Project Management is how you deliver high value and technical quality within your time and budget constraints. However, the principles go beyond software development. It’s a mindset for people who need a management approach that builds consensus quickly in a fast-paced environment.
Time to Market
What the Analysts Say
1. Reduced time-to-market
2. Increased quality
3. Reduced waste
4. Better predictability
5. Better morale
Agile projects are 37% faster to market than industry average.
The Agile Paradigm Shift
What Agile is NOT
A specific methodology
– It’s an umbrella term for a set of approaches which share common values
– Rather, a synergistic set of highly disciplined practices
Working without planning
– Adaptive planning instead of following a plan
Suitable for all types of projects
– Unavailability of customers and pre-defined requirements may sway projects to other approaches
A silver bullet
– The project could still fail… but it will fail faster
Agile Manifesto for Software Development
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
“While there is value in the items on the right,
we value the items on the left more”
12 Principles behind Agile Manifesto
1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity – the art of maximizing the amount of work not done – is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Bottom Line Agile
Focus on customer value
Deliver early and often
Working software is the primary measure of progress
Inspect and adapt
The Scrum Framework
Scrum Project Lifecycle
Scrum is Light-Weight
• No mention of issues or risk management, quality assurance, configuration management, story boards, etc.
• Anything additional that you do needs to support the Agile manifesto.
• Any additions are inspected and adapted by the team as part of the sprint retrospective.
Sprint burndown chart
Release burnup chart
• Coach, inspire, and lead teams more than they measure and manage them.
• Focus on the organizational environment’s ability to deliver value
“If you fail to honor your people, they will fail to honor you;
It is said of a good leader that When the work is done, the aim fulfilled, the people will say ‘We did it ourselves.’ ”
The Scrum Team = 7 (+/- 2 people)
• Scrum Master
• Product Owner
• Removes impediments
• Enforces values and practices
• Protects the team
• Develops team members skills
• Facilitates ceremonies
• Escalates issues on behalf of the team
• Develops and communicates the vision
• Represents (or is) the customer
• One voice, even if not one person
• Develops the product roadmap and release plan
• Accepts or rejects work results
• Addresses team’s questions
• Grooms the backlog and sets priorities
• Breaks down user stories into tasks
• Estimate tasks during Sprint planning
• Works on design/code/test/integration for each task
• Supports other team members
• Continues to work through tasks until no tasks remain in Sprint backlog
• Participates in sprint demos and retrospectives
• Technical expertise
• Cross functional – analysis /design /development / testing
• Collaborative team player – voluntarily offers assistance as needed
• Good communicator – knows to ask for help so the team stays on track
Release Schedule looks easy – but the confidence to commit requires the rigor of Release Planning
0) Estimate team capacity
1) Discuss highest priority story from the product backlog
2) Size the user story
3) Break story into tasks
4) Task owner estimates task in hours
5) Repeat 1-5 until capacity is reached
Plan to the Team’s Capacity
1. Collect available hours before the sprint planning session
2. Build in a buffer
3. Stop when the team reaches capacity
Ensure a sustainable pace
Ensure that the team has enough work
Level-load the work
Deduct Time from Capacity for the Following Scrum Practices
Release Planning Session
– ~4 hours
– at least once per release
– ~2 hours for each 2-week sprint
– 15 minutes per day
– 1.5 hours per sprint
– 30 minutes per sprint
Commit to the Work
“On a scale of 1 to 5, how confident are you that we can complete the user stories in the sprint plan by the end of the sprint?”
Daily Scrum or Standup
• Brief (10-15 min) daily meeting
• Assures continual team communication
• Drives accountability (peer-pressure, transparency)
• Demonstrates day-to-day progress to all team members and stakeholders
Everyone answers 3 questions
1. What did you do yesterday?
2. What will you do today?
3. Is anything in your way?
These are not status for the Scrum Master, they are commitments in front of peers.
• Review of sprint metrics
• Live demonstration by the people who did the work
• 2-hour prep time rule
• No slides
Invite all interested parties
Open forum – collect feedback
The Definition of Done
Each delivery team needs to define their definition of when a user story is considered to be “DONE.”
Has the code been promoted to QA/TEST environment?
Has the code passed functional testing?
Has documentation been updated?
Has the code undergone peer code review?
Only when a user story meets all the criteria of done, (i.e., DONE/DONE) can the team claim credit for completing the story/functionality.
Note: Incomplete work cannot be demonstrated!!
Commit-Accept (Say-Do) Ratio
This diagnostic metric reflects team progress by completion of its work commitment.
Total story points accepted by the Product Owner Total story points committed for completion by the team
The higher the Say-Do Ratio, the better. For instance, if a team commits to finishing 40 story points in a sprint, and the PO only accepts 36 story points, the Say-Do Ratio equation is:
(36/40)*100 = 90%
A team can identify/inspect delivery problems then take corrective action(s) as required.
By meeting its work commitments, a team build trust with the PO/client supported.
• Team reviews sprint successes and short falls
• What could be done different in subsequent sprint?
• Build in continuous improvement to agile process
• Vital to success of agile development
Net Promoter Score How do customers feel about our product?
Promoters (score 9-10) Loyal enthusiasts who will keep buying and refer others, fueling growth.
Passives (score 7-8) Satisfied but unenthusiastic customers who are vulnerable to competitive offerings.
Detractors (score 0-6) Unhappy customers who can damage your brand through negative word-of-mouth.
Sprint Burndown Chart
Scrum Team Velocity
Velocity is the average number of user story points a delivery team completes during a sprint. It’s used to gage of how much work a team is capable of delivering. Benefits:
• Team velocity enables the Product Owner to forecast how much work a team can be expected to complete – based on the team’s own estimate of effort.
• With an established team velocity, the Product Owner can plan future releases with improved predictably.
The team’s goal is to gain and sustain a consistent velocity across releases.
Purpose of User Story
A user story is an agreement to have a conversation
Product Backlog – “The Work”
• Owned and maintained by the Product Owner – stack ranked by business value offered – most important at top
• Master list of desired product functionality expressed as user stories
• One Product Backlog per delivery team
• Initiates the development process
• High priority items are used to create the Sprint Backlog
• Each user story provides value
• Grows & changes as more information is acquired
Sample Backlog Grooming Checklist
Clarify stories (e.g., title, description, notes, etc.)
Assign initial point estimates (i.e., 1, 2, 3, 5, 8, 13, 20, 40, 100)
Break down “epics” into smaller stories
Identify any risks and dependencies
Tag stories (e.g., administrative, technical spike, CRM, etc.)
Add acceptance criteria
Add any known tasks
Change status in Rally from “B” (backlog) to “D” (defined)
Breaking Down User Stories
Splitting User Stories
Remember: Don’t split or detail Product Backlog Items until they are declared sufficiently valuable for the product
Estimating User Stories
We’re not very good at estimating…
Begin by estimating the effort for what the team agrees is a medium story
Story 1/2/3 – Complexity, Effort, Doubt
1. Read the user story, discuss briefly to ensure clarity
2. Each team member selects an estimate card Fibonacci sequence (1, 2, 3, 5, 8, 13) — any higher (20, 40, 100) means story needs more clarification
3. Cards are all turned over at once
4. Discuss the high and low cards
5. Re-estimate once more
6. SM makes the final call
Planning Poker acts to:
• Identify consensus quickly
• Democratize the discussion, so we hear from all voices!
• Uncover assumptions
• Team learns to collaborate on decisions
Agile Manifesto for Software Development
Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan
“While there is value in the items on the right, we value the items on the left more”
The Scrum “Fractal”