Agile Project Management For Dummies Cheat Sheet

Agile project management is becoming agile product development. Products are considered long-term, value-creating assets requiring permanent teams who iteratively elaborate, design, develop, test, integrate, document, and even support products until business outcomes are achieved. Agile product development focuses on continuous improvement, scope flexibility, team input, and delivering essential valuable outcomes. Agile development approaches often include scrum as a framework for exposing progress, a variety of technical practices for building in quality upfront, and lean thinking to eliminate waste. These and many other tools and techniques help organizations, teams, and individuals adhere to the Agile Manifesto and the 12 Agile Principles, which focus on small, long-lived, self-organizing teams, effective communications, continuously releasable product, and flexibility.

Manifesto for Agile Software Development

The Manifesto for Agile Software Development, commonly known as the Agile Manifesto, is an intentionally streamlined expression of the core values of agile project management and product development. Use this manifesto as a guide to implement agile practices into your products.

“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.”

©Agile Manifesto Copyright 2001: Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas.

This declaration may be freely copied in any form, but only in its entirety through this notice.

12 Agile Principles

The principles behind the Agile Manifesto, commonly referred to as the 12 Agile Principles, are a set of guiding concepts that support product teams in implementing agile product development and project management techniques. Use these principles as a litmus test to determine whether or not you’re being agile in your product work and thinking:

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.

The Platinum Edge Roadmap to Value

The Roadmap to Value, shown in the following figure, is a high-level view of an agile product development cycle.

Following is a description of the Roadmap to Value:

• The product goal is the long-term objective for the scrum team. The product owner establishes the product goal in collaboration with stakeholders and scrum team members. On longer development efforts, revisit the product goal at least once a year.
• The features and value needed to accomplish the product goal are visualized through the product roadmap. In collaboration with the customer, stakeholders, and scrum team, the product owner creates the product roadmap as a high-level view of the product requirements, with a general time frame for when those requirements will be developed. The product roadmap also gives context to the product goal by showing the tangible features that will be produced during development. Identifying product requirements and then prioritizing and roughly estimating the effort for those requirements allow you to establish requirement themes and identify requirement gaps. The product owner, with support from the developers and stakeholders, should revise the product roadmap at least semiannually.
• The release plan, created by the product owner in collaboration with the customer, stakeholders, and scrum team, identifies the valuable functionality the scrum team intends to release to the customer next. The release serves as a mid-term boundary against which the scrum team can mobilize. A product developed using agile techniques will have many releases, with the highest-priority features appearing first. You create a release plan at the beginning of each release, which is usually at least quarterly. Releases can also happen more frequently. Some organizations release multiple times a day.
• Sprint planning is the first event of an iteration called sprint in scrum, where the product owner, the developers, and the scrum master plan how they will do the work of creating the product functionality in the sprint. Sprint planning takes place at the start of each sprint. During sprint planning, the scrum team determines a sprint goal, which establishes the immediate boundary of work that the team forecasts to accomplish during the sprint and why it’s important to the customer. They also pull from the product backlog the requirements needed to accomplish the sprint goal and outline how the team will work together.
• Each day of the sprint the developers meet in their daily scrum to inspect progress toward the sprint goal and plan and coordinate their day’s work. The developers can select whatever structure or technique they want as long as it helps the team focus on progress made toward the sprint goal and produces an actionable plan for the day’s work. The scrum master may attend daily scrums to coordinate removal of impediments. The product owner may attend the daily scrum to enjoy the transparency of progress and provide any clarification needed by the developers, and stakeholders may attend to enjoy the transparency. But the daily scrum is for the developers and by the developers, not for others to disrupt.
• At the end of every sprint, the scrum team holds a sprint review. In the sprint review, you demonstrate the working functionality to the product stakeholders for their immediate feedback. The product owner then ensures the product backlog is updated to reflect the feedback.
• Lastly, the scrum team holds a sprint retrospective, where the scrum team plans ways to increase quality and effectiveness. They inspect how the last sprint went with regards to people, interactions, processes, tools, and the definition of done (standard of quality). Like the sprint review for inspecting and adapting the product, a sprint retrospective is held at the end of every sprint to inspect and adapt the team’s processes and environment.

Agile product development accountabilities

It takes a cooperative and collaborative team of people to successfully develop a product. Agile product teams are made up of many people and include the following five accountabilities and roles:

• Product owner: The person accountable for maximizing the value of the product resulting from the work of the scrum team. They bridge the gap between the customer, business stakeholders, and the developers, facilitating collaboration between all three roles. The product owner is an expert on the product and the customer's needs and priorities. The product owner works with the developers daily to help clarify requirements and shield them from business prioritization noise. The product owner, above all, should be empowered to be decisive, making tough business decisions every day.
• Developers: The people who create the product. Developers, programmers, analysts, testers, designers, writers, engineers, editors, and anyone else with a hands-on role and the skills needed for creating the product are developers. Developers are cross-functional and have multiple skills they contribute to the product development work. Most importantly, developers are versatile, able to contribute in multiple ways to the product’s goal.
• Scrum master: The person accountable for the scrum team’s effectiveness. They support the team, ensuring organizational roadblocks are cleared, and foster an environment where products can be successfully developed using the empirical pillars of unfettered transparency, frequent inspection, and immediate adaptation. Scrum masters are true leaders, and are most effective when they have organizational clout, which is the ability to influence change in the organization without formal authority.
• Stakeholders: Anyone with an interest in the product. Stakeholders are not ultimately responsible for the product, but they provide input and are affected by the product’s outcome. The group of stakeholders is diverse and can include people from different departments, customers, users, or even different companies. For product development efforts to succeed, stakeholders must be involved, providing regular feedback and support to the developers and product owner. This role is outside the scrum team, but we explicitly acknowledge the role’s involvement to improve scrum team success.
• Mentor or coach: Someone who has experience implementing agile product development techniques and can share that experience with an organization. The mentor can provide valuable feedback and advice to new teams and to teams that want to perform at a higher level. Although mentors are not responsible for executing product development, they should be experienced in applying agile principles in reality and be knowledgeable about many agile approaches and techniques. This role is outside the scrum team, but we explicitly acknowledge the role’s involvement to help improve team and organizational success.

Agile product development artifacts

Product development progress needs to be transparent and measurable. For agile product development teams, especially those using scrum, three scrum artifacts and usually three other helpful tools enable transparency, inspection and adaptation, as listed here:

• Product backlog: The product’s to-do list — an emerging list of what is in the scope for your product, ordered by priority. After you’ve identified your first requirement, you have a product backlog. Product backlog items support the accomplishment of the product goal.
• Sprint backlog: The goal, user stories, and tasks associated with the current sprint. The sprint backlog supports the accomplishment of the sprint goal.
• Increment: The working and valuable product functionality, demonstrated to stakeholders at the end of the sprint, which is potentially releasable to the customer. When the definition of done is met, an increment is born.

Following are other helpful tools and artifacts used by many successful scrum teams:

• Product goal: The product goal describes a future state of the product, which serves as a target for the scrum team to plan against. It’s an inspirational elevator pitch, or a quick summary, to communicate what your product will be and how your product supports the company's or organization's strategies. The scrum team commits to accomplishing the product goal.
• Product roadmap: The product roadmap is a high-level initial view of the product features needed to achieve the product goal. It also enables a scrum team to outline a general time frame for when those requirements will be developed and released. The product roadmap is a first-cut, high-level view of the product backlog that identifies gaps and feature affinities, enabling funding committee decision-making with a reasonably complete picture. This artifact is outside scrum but improves scrum team success.
• Release plan: The release plan is a high-level timetable of the next set of functionality for release to the customer. This artifact is outside scrum but improves scrum team success.

Agile product development events

Most products navigate various levels of planning. Agile product development efforts using scrum include five scrum events, plus two others most scrum teams follow to establish strategic direction:

• Product planning: The initial planning for your product. Product planning includes creating a product goal and a product roadmap, and can take place in as little time as one half of a day. This event is outside of scrum but improves scrum team success.
• Release planning: Planning the next set of product functionality to release and identifying an imminent product launch date around which the scrum team can mobilize. With agile product development, you plan one release at a time. This event is outside of scrum but improves scrum team success.
• Sprint: A short cycle of development, in which the team creates valuable product functionality. Sprints, the scrum term for iterations, typically last between one and four weeks. Sprints can last as little as one day, but are commonly one or two weeks. Sprints should remain the same length throughout product development, which enables teams to plan future work more accurately based on their past performance. Shorter sprints provide more frequent opportunities to adapt and learn.
• Sprint planning: An event at the beginning of each sprint where the scrum team commits to a sprint goal. They also identify the requirements that support this goal and will be part of the sprint, and the individual tasks it will take to complete each requirement.
• Daily scrum: A 15-minute or less coordination and synchronization event held each day in a sprint, where developers inspect their progress toward the sprint goal so they can adapt and plan together their day’s work.
• Sprint review: An event at the end of each sprint, introduced by the product owner, where the developers demonstrate the working product functionality it completed during the sprint to stakeholders. The product owner collects feedback for updating the product backlog.
• Sprint retrospective: The last event of each sprint where the scrum team plans ways to improve the team’s quality and effectiveness by inspecting and adapting their processes, tools, environment, skills, communication, and distractions. They discuss what went well and what could change; and make a plan for implementing improvements in the next sprint.