More than simply a methodology or approach to software development, Agile embraces a set of principles that drive more effective software development. Agile focuses on the customer, embraces the ever changing nature of business environments and encourages human interaction in delivering outstanding software. In this introduction, we'll discuss the following:
- What is Agile?
- Agile Manifesto
- Agile Principles
- Agile Methodologies
- Agile Benefits
- Requirements Reality
Forming the Agile Team
Agile Teams embrace cross-functional collaboration and understand that the individual succeeds only when the team succeeds. We will discuss how to form the Agile Team, appropriate teams size, how the Product Owner fits in, as well as the following topics:
- Team Roles and Responsibilities
- Self Organization
The Role of the Product Owner
The Product Owner plays an integral role on an Agile Team. Without the input and direction from the PO, the team makes assumptions and often inappropriate decisions about the product that are not aligned with what the customer actually wants. Here we will discuss the role of the Product Owner, how they provide direction for the team and how they engage with the team to allow the right product emerge for the right customers.
- Role and responsibilities of the Product Owner
- Agile Product Management
- Working with the team
- Working with management
- What to expect Section
The Agile framework embraces a methodical process of planning that goes into 5 levels of detail. Rather than mistakenly getting to the details too soon of ever-changing requirements, Agile planning helps us focus on the right level of detail for the right priorities at the appropriate time. In this section we'll cover the following:
- The Agile Framework
- 5 Levels of Planning
- Product Vision
- Class Exercise: Working in small teams, you will "design the box" in order to establish a vision for a sample project. You will participate in identifying key selling points, features, operating requirements, etc.
Focus on the Customer
It is critical that the customer be the focus of a product throughout the development lifecycle. Every requirement should bring some value to the customer. Therefore, prior to defining requirements, it is important to define the customer. This will include the following topics:
- Customer Involvement
- User Roles
- Creating and Using Personas
- Class Exercise: Within your teams you will brainstorm some user roles for your example project. From the brainstorming, you will consolidate the larger list of roles into key roles that will be the focus of your sample project, For each of the key roles, each team will create personas and share them with the class.
Creating the Product Backlog
The Product Backlog is the complete list of desired elements, or requirements, for the product. It consists of User Stories (requirements from a customer point of view), Foundational Stories and any other work items the team must complete. Stories do not capture all of the detailed requirements, but require enough information to estimate, plan and facilitate verbal requirements discussions at the appropriate time.. In this section we will explore the following:
- The Product Backlog
- User Stories
- INVEST Model (Bill Wake, 2003)
- Goals and Objectives
- Acceptance Criteria and Acceptance Tests
- Foundational Stories
- Low-Fidelity Prototypes
- Class Exercise: With your teams, you will engage in a story-writing workshop as a means of building a product backlog for your sample project. We will also introduce low-fidelity prototyping as a way to generate additional stories.
Guidelines to Writing Effective User Stories
Since we build the Product Backlog through the utilization of User Stories, we will talk through some guidelines and tips for writing effective User Stories, how to break them down when necessary and how to clearly identify requirements valuable to users.
- Start with Goal Stories
- Slice the Cake
- Open vs. Closed Stories
- Story Constraints
- Size the Story to the Horizon
- Class Exercise: You will individually have an opportunity to break down a predetermined Epic Story into smaller more manageable User Stories.
The Product Roadmap describes the sequence of product releases to make the product strategy a reality. In this section we will talk about grouping User Stories into Product Themes and how to organize those themes into a high level plan providing direction and visibility for the team, management and stakeholders.
- Product Themes
- Two types of Roadmaps
- Creating the Roadmap
- Keeping Focus
- Maintaining the Roadmap
- Class Exercise: Each team will group their user stories into common product Themes, helping teams recognize that at times it makes sense to prioritize beyond just individual user stories. Teams then utilize the product themes to establish a desired product roadmap. Like the vision, the roadmap is then posted for team reference for the remainder of the course.
Prioritizing the Product Backlog
Prioritization is often done at a level that excludes the development team and fails to account for the technical expertise the team provides in determining dependencies, impact, risk and the sequencing of work items. In this section we explore methods of prioritization and how PMs can help the business and development groups collaborate together to determine the right priorities. We will peruse the following topics:
- Prioritization Themes
- Decision Matrix
- Kano Analyis
- Preventing Fire Alarms
- Maintaining the Product Backlog
- Class Exercise: Utilizing the prioritization techniques discussed, you will prioritize the Product Backlog for your sample project taking into account the dependencies, risk and impact of your user stories.
Among the greatest challenges in developing software and delivering against stakeholder expectations is estimating accurately and subsequently planning how those expectations can be met. Agile cannot make that challenge disappear, but offers some very helpful tools that enable teams to set and meet the appropriate expectations. Product Owners should understand their role in the estimating process providing direction and product details to the team.
- Relative vs. Actual Estimating
- Introduction to Story Points
- Effectively Using Story Points
- Planning Poker (Grenning 2002)
- Product Planning Poker (Business Value)
- Class Exercise: Using the estimating techniques taught using story points, you'll enjoy a few rounds of Planning Poker, a fun and very effective method of relative estimating, with your team to establish estimates for your highest priority stories. This is certain to be a valuable tool for you to incorporate into your estimating process; specifically your estimates of business value.
The release plan identifies a goal for the stories that will be included for a release of the software. Through the prior processes, the team will have prioritized the stories and estimated the team velocity. These key elements will come together to give the team a level of confidence that they can deliver the necessary requirements for a product release in what is normally a fixed timeframe. We'll examine the following topics:
- What is a Release
- Schedule Based vs. Feature Based Planning
- Building the Release Plan
At the appropriate time, prior to entering into the development of a story, requirements will need to be discussed in more detail. The instructor will introduce several methods for helping Product Owners lead their teams in "getting to the details" of Agile Requirements.
- Unused Requirements
- Adapting to Change
- Test Driven Development
- Use Cases
- Alternative Methods
- What is Important
Iteration Planning and Execution
An iteration is a fixed amount of time in which stories/requirements will be developed, tested and ready for release. Product Owners need to understand how to engage the team and provide the necessary direction to effectively break out the tasks, hours and assignments for the Iteration. We'll also discuss how POs can be engaged with the team as they execute the Iteration and provide the right deliverables and measurements to help you make decisions about the product.
- Engaging the Team
- Planning the Iteration
- Executing the Iteration
- Defining "Done"
- Demonstrate Working Software (Delivered Requirements)
- Inspect and Adapt applied to Requirements
The Retrospective is one of the key practices of Agile and is the inspect and adapt mechanism for the team. Product Owners should help the team identify what is working, what is not working and what specific areas need to be improved.
- Elements of the Retrospective
- Facilitating Retrospectives
- Improvement Backlog from Retrospectives
- Class Exercise: The instructor will facilitate a Retrospective for the class allowing participants to provide feedback for the course in addition to demonstrating how a Retrospective should be run.
Adopting Agile Product Management
This last section is where we bring everything together and discuss specific implementation strategies, how to overcome resistance and several additional tips to effectively manage Product Development Cycles in an Agile environment. Topics covered include:
- Agile Process Overview
- Overcoming Resistance
- How to get Started
- Agile Calendar of Events
- Challenges to Adoption
- Team Roadmap Exercise