Agile Project Management

Agile Project Management
L e a d i n g C h a n g e T h r o u g h C o l l a b o r a t i o n Agile Project Management

Pollyanna Pixton Founder, Accelinnova President, Evolutionary Systems
L e a d i n g C h a n g e T h r o u g h C o l l a b o r a t i o n Pollyanna Pixton Founder, Accelinnova President, Evolutionary Systems Director Institute of Collaborative Leadership

Agenda What is Agile Agile Methods Scrum Deep Dive
Estimating and Planning Getting Started Leading Agile

What is agile?

“Find your joy in something finished, and not a thousand things begun
- Douglas Mallock 5

Project Methods Waterfall: New Methods:
Function Definition, Design, Build, Check Functions Design Build New Methods: Single Cycle Review and Adjust Spiral: Multiple Cycles of Waterfall Agile: Adapt As You Go: Short Iterations Check Done

What is Agile? From recognition and acceptance of increasing levels of unpredictability in our turbulent economy A chaordic perspective Collaborative values and principles Barely sufficient methodology - Jim Highsmith

Agile Encourages Mid Course Corrections
Zone of success Planned Completion Increasing Knowledge Planned Path Start Actual Path As Knowledge increases Leaders use iterations to guide project towards enhanced goal Agile allows you to steer the project through mid course corrections. It’s never possible to plan perfectly. Agile (with stakeholder feedback) Iterations give you a way to compensate for the lack of perfect information during initial planning. As Eisenhower said “Planning is essential. The Plan is worthless.” Actual Completion 8 8 8 8

Business Driven – Faster & More Rewarding
Time Cost Profit Investment Breakeven Single Release Self-Funding Software by Numbers by Mark Denne and Jane Cleland-Huang Staged Releases Agile projects have a break-even point earlier in time than a traditional waterfall project for applications of the same size. Agile projects are more flexible. Can be stopped or restructured without losing all value.

Agile Defined…

uses continuous stakeholder feedback
Many terms are used for use cases/user stories/storypoints – bottom line, effective understanding of how end users will use the software/features and what gets tested to meet the high quality consumable code piece of the definition. Iterative development – who has shipped a product recently? What release criteria was supposed to be addressed/ did you meet that criteria? Criteria should be criteria you grow into with each iteration (2 wk iterations right?) Jeff Sutherland – adds additional criteria to his releases **** must be deployed in a clients production environment, he does this in 1 week iterations but it took him 4 years to get to this point.

insiders principles end users partners
uses continuous stakeholder feedback principles end users partners insiders Carl Kessler and John Sweitzer, Outside-in Development Many terms are used for use cases/user stories/storypoints – bottom line, effective understanding of how end users will use the software/features and what gets tested to meet the high quality consumable code piece of the definition. Iterative development – who has shipped a product recently? What release criteria was supposed to be addressed/ did you meet that criteria? Criteria should be criteria you grow into with each iteration (2 wk iterations right?) Jeff Sutherland – adds additional criteria to his releases **** must be deployed in a clients production environment, he does this in 1 week iterations but it took him 4 years to get to this point.

…to deliver high quality, consumable working code/features

… through user stories 14 14

…and a series of short, stable, time-boxed iterations.
Many terms are used for use cases/user stories/storypoints – bottom line, effective understanding of how end users will use the software/features and what gets tested to meet the high quality consumable code piece of the definition. Iterative development – who has shipped a product recently? What release criteria was supposed to be addressed/ did you meet that criteria? Criteria should be criteria you grow into with each iteration (2 wk iterations right?) Jeff Sutherland – adds additional criteria to his releases **** must be deployed in a clients production environment, he does this in 1 week iterations but it took him 4 years to get to this point.

Agile Defined… Uses continuous stakeholder feedback to deliver high-quality, consumable code through user stories and a series of short, stable, time-boxed iterations.

What is Agile? A development process that conforms to the values and principles of the Agile Alliance (agilealliance.org) Originally for software development

Agile Manifesto While there is value in the items on the right we value the items on the left more. Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan

Agile Overview Agile: Iterative and Incremental to deliver working software Light-Weight Meets Changing Needs of Stakeholders Highly Collaborative: Involves Customers Minimizes Documentation Test First

Example: Legacy Highway

Agile Principles

Light Weight Utilize only practices that make sense for the project and environment “Barely sufficient” artifacts, methodology, and documentation “Appropriate” vs “Best Practices”

Practice Excellence Requires self discipline to improved quality
Relies on the team to practice technical excellence instead of imposing discipline Adopt technical practices that support the other practices such as: Continuous Integration Test Driven Development Refactoring

Reflect and Adapt Learn from past to improve performance
Retrospectives after each iteration Harness change for improved efficiency Multi-Horizon planning allows adaptation

Key Characteristics of Successful Agile Projects
Short, Stable, Time-Boxed Iterations Stakeholder Feedback Self-Directed Teams Sustainable Pace Bring the points previously together to review these characteristics… Ask everyone their perspective around iteration (what is it, how long is it) – Ted likes to promote the idea of 2 week iterations but the class may pick a different length. The first two features are critical towards achieving stable consumable code, the last two features focus on developing/identifying how the team works together and in what fashion. You can choose to discuss what the difference is with self-directed vs self-motivated teams? What are the terms and what do they mean. The term self- directed is intended to promote motivation

The Process Pendulum Code and Fix Agile Waterfall No Process Empirical
Prescriptive I LOVE this!!!!!!! Empirical Frequent inspection Collaboration Adaptive responses Prescriptive Defined set of steps to follow Plan the work, work the plan Plan is assumed to be correct

Project Definition and Iterations Completed Deliverables
Project Methods Envision Iterate: Plan Implement Done? Adapt Complete Project Definition and Iterations Planning Review and Adjust Implement Done? NO YES Completed Deliverables

Agile Cycles High Level Planning Detailed Planning Vision
Iterations Plan Iteration Planning Review / Adapt Iteration Plan Planning Develop High Level Planning Detailed Planning

How Does Agile Work? “Requirements” called features, defined using user stories: As a <user/role> … I want to <goal> … so that <value>.

Agile ‘Process’ User stories listed in a backlog.
Backlog prioritized based on value. Highest priorities estimated and grouped into an iteration (sprint), two weeks long. At end of iteration, ask if enough value to go to market? Add any new user stories to backlog and reprioritize and select next iteration/sprint.

Agile ‘Process’ Test cases are written first, before anything is developed Go/no-go decisions reached early and often

Agile MUST be Disciplined
Agile development necessitates greater discipline than traditional methods. “Quality” and “Consumability” must be real, not platitudes. This is a highly-disciplined activity Consumability = Capability, Usability , Performance, Maintainability, Documentation, Customer Satisfaction, High Quality All describe the “consumability” of software. The diagram is called the Triple Constraint – (a PM term) the notion is that if cost is constant then we could potentially move the little balls and ultimately something might have to change… so to increase function, we lose quality, if we need to focus on speed to market, then quality and functionality will be affected. The point is that in adopting agile, all three of these things aren’t constrained any more.

“It is a bad plan that admits to no modifications. ”
“It is a bad plan that admits to no modifications.” Publius Syrus (ca. 42 BCE) Project Management

What is agile Summary

Agile Defined… Uses continuous stakeholder feedback to deliver high-quality, consumable code through user stories and a series of short, stable, time-boxed iterations.

References What Is Agile Software Development? Jim Highsmith, CrossTalk, the Journal of Defense Software Engineering The New Methodology, Martin Fowler Why Agile (video)

User Stories Your Questions?

Project Management Remove Obstacles Agile Methodologies

Agile Methods eXtreme Programming, XP (Kent Beck, Ron Jeffries, Ward Cunningham) Scrum (Jeff Sutherland, Ken Schwaber, Mike Beedle) Feature Driven Development, FDD (Peter Coad, Jeff DeLuca) Crystal Methods (Alistair Cockburn) Dynamic Systems Development Method, DSDM (DSDM Consortium) Lean Development (Bob Charette, Mary and Tom Poppendieck)

Agile Overview “Agile projects succeed when the team gets the spirit of agility.” – Ron Jeffries, XP Thought Leader

eXtreme Programming

XP Values and Principles
Communication Simplicity Feedback Courage Quality Work

XP Practices The Planning Game Small Releases Metaphor Simple Design
Refactoring Test-First Development

XP Practices Pair Programming Collective Ownership
Continuous Integration Sustainable Pace On Site Customer Coding Standards

XP Roles The Customer The Developer The Tracker The Coach
Sets project goals and makes business decisions The Developer Turn customer stories into working code The Tracker Keeps track of any metrics used by team The Coach Guides and mentors team

Scrum Roles Scrum Team Scrum Master Product Owner
Carries water and moves boulders Product Owner Responsible for maintaining product backlog

Scrum Control Points Meetings: Sprint Planning Daily Scrum
Sprint Review (retrospectives and demo)

Feature Driven Development (FDD)
Model-driven short-iteration process that consists of five basic activities: Develop Model Build Feature List Plan By Feature Design by Feature Build By Feature Deploy - Jeff deLuca, 1997

FDD Focus (Object) Modeling centric Client centric
Architecture centric Pragmatic Functional decomposition Subject Area Business Activity Business Activity Step

FDD Roles Chief Programmers Class owner Feature teams
Team lead, mentor, developer Class owner Developer with responsibility for a class Feature teams Temporary groups of developers formed around classes

Crystal Clear Frequent Delivery Reflective Improvement
Osmotic Communication Personal Safety Focus Easy Access to Expert Users Automated Tests Configuration Management Frequent Integration

Crystal Clear “The team can reduce intermediate work products as it produces running code more frequently, as it uses richer communication channels between people.” - Alistair Cockburn

Crystal Clear “Every product is slightly different and evolves over time, so the methodology, the set of conventions the team adopts, must be tuned and evolve.” - Alistair Cockburn

Crystal Clear Roles Sponsor: Allocates money for the project
Expert User Lead Designer Lead Technical person, mentors less experienced team members Designer-Programmer Each person designs and programs

DSDM Active user involvement Teams empowered to make decisions
Frequent delivery of products Fitness for business purpose Iterative and incremental delivery All changes reversible Testing throughout lifecycle Collaboration with all stakeholders

Agile Method’s Focus Methodology Structure Project Management
DSDM Project Management Engineering Scrum Crystal FDD XP Structure I LOVE this!!!!!!! DSDM Unstructured Structured Crystal FDD Scrum XP

Lean Manufacturing Optimizing production through removal of waste and improving flow A process management philosophy based on Toyota Production System (TPS) Focus effort on producing value- added features Just in time delivery

Lean Software Development
Everything not adding value to customer is waste includes: Unnecessary code and features Delay in development Unclear requirements Bureaucracy Slow internal communications By Mary and Tom Poppendieck

Project Management Agile Project Management:
The PM is the person who facilitates the team's work, removes obstacles, manages risks, and explains to management what is going on. Good PMs are on the side of the team, because that's how the product gets delivered. The ScrumMaster facilitates the team's process and removes obstacles for the team.

Project Management Agile Project Management:
Following the values and principles of the Declaration of Interdependence (DOI) Written by the founders of the Agile Project Leadership Network (apln.org)

Declaration of Interdependence
Continuous flow of value Engage customers Create an environment where individuals can make a difference Expect uncertainty and manage for it Context specific strategies, processes, and practices Group accountability

Why Use Agile …

Project Challenges

Project Statistics Standish Group Study, reported by CEO Jim Johnson, CIO.com, ‘How to Spot a Failing Project’

Project Statistics Improvements Due To Better: Tools Project Managers
Adaptive Methods Breaking projects into small chunks Delivering pieces faster for user feedback

Standish Group Study, reported by CEO Jim Johnson, XP2002
Never or Rarely Used: 64% Always or Often Used: 20% Rarely 19% Sometimes 16% Often 13% Never 45% Does this help us realize that we often over-engineer our designs? The Never and Rarely used not only represent our over-investing in some features and functions, that work might have kept us from developing features and functions that would help us win in the marketplace. Google Docs are competing with MS by only implementing the elements of MS Office that people actually use. Always 7% Standish Group Study, reported by CEO Jim Johnson, XP2002

Failures Main Reasons For Project Failure :
Lack of end user involvement Poor requirements Unrealistic schedules Inadequate change control Lack of testing Inflexible processes

Success Factors User involvement Management support
Clear vision & objectives Proper planning Realistic expectations Smaller milestones Competent staff Ownership

Challenges Deliver the right product Meet customer’s changing needs
Deliver to rapidly moving market windows Innovate on both sides of your business model Get more done by doing less Lead in the marketplace

Companies Must… Deliver Business Value Increase Productivity
Lead Change Find Solutions Innovate

Project Management Remove Obstacles Agile Methodologies Summary

Agile Methods Summary eXtreme Programming, XP Scrum
Feature Driven Development, FDD Crystal Methods Dynamic Systems Development Method, DSDM Lean Development

Scrum Deep Dive

Scrum on a Page Roles Artifacts Meetings Stakeholders Product Owner
Scrum Master Team Product Backlog Release Backlog Sprint Backlog Blocks List Information Radiator Artifacts Release Plan Meeting Sprint Plan Meeting Daily Scrum Sprint Review Meeting Meetings Concept inspired by William Wake’s “Scrum on a Page,”

Definitions Roles

Stakeholders Anyone that can give input to the business objectives of the product.

Types of Stakeholders Principals End Users Partners Insiders
Stakeholders who champion the need for your software and have the authority to acquire and deploy it. End Users Stakeholders who personally interact with your software. Partners Stakeholders who make your product work in real life, such as operations teams and also business partners and system integrators. Insiders Stakeholders within your own organization; such as developers, support engineers, sales, architecture, and marketing teams.

“ The customer is always moving, changing, and if you’re not out there all the time trying to understand the functional and emotional needs of consumers, your design will simply fall flat. - Matthew May “ Consider this quote… what is your reaction to reading this? Is it true? Do you feel its an exaggeration? Have you had instances where your customers HAVE changed and the product was too late?

Outside-in development is a set of principles that focus teams on developing software which helps stakeholders be successful in their business. Problem: Solutions don’t work as imagined. Cause: The facts aren’t clearly understood. Solution: Learn to see. Goal: Get inside the [stakeholder’s] mind. Understanding Your Stakeholders Aligning with stakeholder goals Defining Success in Your Stakeholders’ Term Making Products Consumable Understanding Organizational Context Outside-In Software Development

I can’t imagine a world without
Your product Not only could I imagine a world without it, I long For it It usually does what we want, if painfully at times Without it, our business would suffer, and I would feel a sense of personal loss “ “ You know you’re lean when: customers pull compelling value from you effortlessly. One of “the eleven questions making up [the Gallup Organization’s] ‘Customer Engagement’ survey,” as cited by Matthew May, The Elegant Solution (New York: Free Press, 2007), 126. Quote from page 182.

Product Owner Prioritizes backlog in collaboration with …

Scrum Master Removes the barriers between development and the customer so the customer directly drives development Facilitates creativity and empowerment Improving the productivity of the development team in any way possible Improving the engineering practices and tools so each sprint is ready to deploy

Scrum Master Is not the project manager
Team manages itself Doesn’t have authority over the team Team makes decisions Always asks the question: “How are the Product Owner and Team doing?” Challenges the organization, key-role in the change However, a dead scrum master is a useless scrum master

Team Teams Add self organizing and ownership bits here.

Unleashing Innovation
Collaboration Process Exercise

Quick Exercise (A) Form pairs Assign one as boss, the other as worker
The boss can give the following commands: Go, Stop, Right, Left, Faster, Slower The worker must follow the boss’s commands Goal: 60 steps in two minutes The boss can command the worker but not touch the worker Lets test this theory shall we? Tell everyone to pair up (into groups of 3 if there are odd number of people)…. Determine who is the boss and who is the workers Get workers to raise their hands and then tell them to ignore the next set of instructions. Bosses, they have 6 words (Stop, Go, Left, Right, Backup, ?) they can use and they have to stay within the bounds of the masking tape, they have to direct the worker to take 60 steps in 2 minutes without crossing the line. Once you have reached 60 steps, stop and raise your hands… The facilitators walk around the room and keep people in the boundaries as well as tell them when then need to start over. Also observe the behaviors and approaches used. Summary discussion – ask the audiences their perspectives… what was it like? Managers typically blame the workers, workers say it was easy… almost everyone “crossed the line”… many workers actually used initiative and stopped at the line without anyone telling them to stop. How much is this like sometimes how work goes?

Quick Exercise (B) Everyone is a worker and responsible for figuring out how to proceed during the exercise Goal: 60 steps in two minutes This time, everyone does this themselves… no bosses only workers, and cut it to one minute if you want to do this quickly. The concept is very obviously achieved … the difference between Exercise 1 and this one. Typically they are MUCH quieter… and they move more quickly… Ask the audience to remark on this exercise… Was it chaotic? Confusing? So apparently the concept of self-direction seems to have merit, right? If we can assume we hire intelligent people? What would be the role of the manager then?

“Self-directed” or “Self organizing” Teams
The concepts of leadership, management, and team involvement are prospectively very different Encouraging a collaborative environment All roles support one another Interpretation of self-management = belief that no one is really working their hardest… this quote came from a previous class that upper management really has a hard time letting people self manage.

example: self-organizing teams: 3M
No rainbow. Something that reps BV.

The “Whole Team” Concept
Coders/programmers ID/Writers Product Champion Architect Designer Product Owner Project Managers Testers Other Roles

Create a Trusting Environment
“ When you're in a ‘trusted’ environment, teams tend to innovate better, more quickly and overall transaction costs are much lower. “ As a team what are you doing to create/contribute to such an environment? Can I describe what such an environment might look like? Feel like? How do I help promote and sustain my team better? Am I helping eliminate waste or am I contributing to wasteful activities or an untrustworthy environment?

Create a Trusting Environment
“ When you're in a ‘trusted’ environment, teams tend to innovate better, more quickly and overall transaction costs are much lower. “ As a team what are you doing to create/contribute to such an environment? Can I describe what such an environment might look like? Feel like? How do I help promote and sustain my team better? Am I helping eliminate waste or am I contributing to wasteful activities or an untrustworthy environment? Sue McKinney VP MSM Development Pitney Bowes

Trust/Ownership Model
Failure No One Cares Energy & Innovation Team Trusted Team Accountable Leader Freed How do we get here? & Business Process Leadership Command & Control Team Does as Instructed No Ownership Leader / Process is Bottleneck Conflict Team Demotivated Mired in Bureaucracy & Wasted Effort Control Low Team/Individual Ownership High

What Does a Trust Environment Feel Like?
Leader’s View The team won't let me down The team understands what we need They will do the right thing They will tell me if they need help

What Does a Trust Environment Feel Like?
Individual within the Team We understand the vision and the need We are jointly committed to meeting our goals We stand or fall together We have Ownership

Self-directed teams: Is this lunacy?
Two principles supporting the Agile Manifesto: Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. The best architectures, requirements, and designs emerge from self-organizing teams. The industry agile manifesto strongly reinforces the concept of self-organizing teams and empowering the individual.

Definitions Roles Summary

Roles in a Nut Shell Stakeholders: gives input as to the product business objectives Product owner: responsible for the business value of the project ScrumMaster: ensures that the team is functional and productive Team: self-organizes to get the work done

Artifacts

Product Backlog The current view of the requirements
Consists of Epic User Stories Prioritised by the Product Owner in collaboration with Stakeholders Prioritized based on Business Value and Risk

Release Backlog Each Release has a theme
Release Backlog contains the User Stories for that release Made up of User Stories (broken down Epic User Stories)

Sprint Backlog Each Sprint has a goal
Team agrees on goal and commits to it User Stories for the Sprint

Blocks List Internal – Actions within the team
External – Actions beyond the team Updated by the Scrum Master Scrum Master resolves them with team

Information Radiator Visual representation of progress Display of:
Work Planned (Product, Release and Sprint) Work in Progress Work Done User Stories to mitigate risk User Stories to gather information to make future decisions

Burndown Chart Part of the Information Radiator

Example

Artifacts Summary

Artifacts Summary Product backlog: prioritized list of desired project outcomes/features (epic user stories) Release Backlog: prioritized list of user stories for the release Sprint backlog: set of work from the product backlog that the team agrees to complete in a sprint Information Radiator: at-a-glance look at the work progress

Meetings Leadership Influence

Sprint Planning Meeting
At the beginning of a new Sprint Chaired by the Scrum Master Attended by all including Key Stakeholders Update the Product Backlog with new requirements Select highest priority items in the backlog based on Business Value Define the Sprint Goal

Daily Scrums Daily 15 minute status meeting
Same place and time every day Chaired by Scrum Master Attended by entire sprint team Others can attend Chickens and pigs (only the deliverers speak)

Daily Scrums Each team member answers: What did you do yesterday?
What are you doing today? What are your blocking issues? No problem solving! Leave after 15 minutes!

Daily Scrum Records Sprint Backlog up to date
Scrum Master updates the blocks list

Sprint Review Meeting Held the last day of the sprint Attended by team
Team demos “done” user stories to stakeholders Requests feedback Team holds retrospective Updates the process for the next sprint

Demonstration Only DONE working user stories.
Ask for attendance from the following for the first 4 iterations as numbered: Executive Internal users Stakeholders Customers

How do you know when you’re “done”?

Team Defines of “Done” Consider: No showstoppers
All errors that the team has not agreed to are removed Code is unit tested, function tested, system tested, performance tested, tested end-to-end A meaningful stakeholder review has been conducted

Team Defines of “Done” Can this really be done? This puts a high premium on: Valuable, maintained, nested automation Appropriate coverage (e.g. 80%) True test-driven development Avoiding technical debt Continuous integration Really understanding what quality looks like

Example “It took us four years to get done, done, done, done.”
Jeff Sutherland (co-creator of Scrum), said PatientKeeper: “It took us four years to get done, done, done, done.” Patientkeeper provides safety critical patient management software

Example What does “Done”, “Done”, “Done” mean? It is fully developed
It is fully tested It has no Severity 1s or 2s It has been deployed before a release in a client environment

Example They ship A major release every 3 months A minor release every month And minor updates once a week Consider the competitors, teams of developers and they cannot achieve the work flow Patientkeeper does.

Retrospective Keep Drop Add Keep? Drop? Add? What surprised you?

Meetings Summary Leadership Influence

Scrum Meetings Summary
Sprint planning: team and product owner choose work to deliver during a sprint Daily scrum: team meets each day to share struggles and progress Sprint reviews: team demonstrates what completed during the sprint Sprint retrospectives: team discusses ways to improve product and process.

Collaboration Process Scrum Exercise

Develop a Brochure in a 3 day Sprint
Complete Sprint Planning Meeting -10min Select at least 5 Product Backlog Items Identify 2 to 3 Tasks per Item Day 1 8 minute day Day 2 2 minute Daily Scrum Meeting Day 3 Demo & Reflection 00 04 03 02 05 01 06 10 09 07 08 02 00 03 01 06 08 04 07 05 00 02 01 02 01 00 03 04 08 07 06 05 00 02 01 02 01 00 03 05 08 07 06 04

Scrum Deep Dive Summary

Scrum on a Page Roles Artifacts Meetings Stakeholders Product Owner
Scrum Master Team Product Backlog Release Backlog Sprint Backlog Blocks List Information Radiator Artifacts Release Plan Meeting Sprint Plan Meeting Daily Scrum Sprint Review Meeting Meetings Concept inspired by William Wake’s “Scrum on a Page,”

Scrum Best Practices Test Driven Development
Pair testers and developers Continuous Integration

References http://scrumalliance.org/pages/ what_is_scrum
scrum_student_resources The Elegant Solution, Matthew May Outside-in Software Development, Carl Kessler and John Sweitzer

References Agile Project Management with Scrum, Ken Schwaber
Agile Software Development with Scrum, Ken Schwaber and Mike Beedle

Scrum Deep Dive - Questions

Leading Agile User Stories Collaboration Model Collaboration Process

User Stories Overview Basics Creating Refine Flow

Leading Agile User Story Basics Collaboration Model Collaboration Process

What is a User Story? A concise, written description of a piece of functionality that will be valuable to a stakeholder. As a <role>, I can <goal> so that <business value>

User Story Roles As a <role>, I want to <goal> so that I can <business value> Avoid “the user” as different stakeholders have different needs M. Cohn recommends using roles so that you do not “miss” stories Teams can develop a set of user roles to help define relevant stories OID is “Outside-in-development”

User Story Goals Goal is “what the role can do”
As a <role>, I want to <goal> so that I can <business value> Goal is “what the role can do” Valuable to a stakeholder Doesn't say “how”, but “what”

User Story Business Value
As a <role>, I want to <goal> so that I can <business value> Justifies the value of the story Clarifies why a feature is useful Can influence how a feature should function Helps prioritize the story in the backlog Can lead to other useful features that support the user’s goals

Example As an < astronaut >
I can < write easily while in Zero gravity > So that < I can record key information that I might otherwise forget >

Example NASA specified and developed, at great expense, a ball point pen that Apollo astronauts could use in space where gravity would not make the ink flow. Russian cosmonauts used pencils. Moral: specify what you want to achieve, not how to achieve it

Exercise At your table, build three user stories

Why use User Stories? Right size for planning, works for iterative development Defer detail until you have the best understanding you are going to have about what you really need Focus on user goals rather than feature attributes

Why use User Stories? Emphasize verbal rather than written communication Potentially fixes issues with “vague requirements” Comprehensible by both stakeholders and the development team Stories support evolutionary development

Where User Stories Help
Value to Stakeholders Stories target functionality valuable to stakeholders Story demos each iteration engage stakeholders In waterfall, you run the risk of designing and coding for a long time before integration and test. A failed design is discovered months later in many cases and is much harder to fix.

Simplified Features Stories enable light-weight requirements gathering, progressive discovery Stories focus on feature essentials In waterfall, you run the risk of designing and coding for a long time before integration and test. A failed design is discovered months later in many cases and is much harder to fix.

Release Predictability Stories by definition fit in time-boxed iteration Stories that fail in an iteration provide early warning system Cadence of story completion over multiple iterations will demonstrate release predictability In waterfall, you run the risk of designing and coding for a long time before integration and test. A failed design is discovered months later in many cases and is much harder to fix.

Leading Agile Creating User Stories Collaboration Model Collaboration Process

Release Themes Release themes are based on business objectives
A well known release theme is critical to team success Themes should embody highest business value needs of the stakeholders and the product

Release Themes Focus on stakeholder success
Focus on product welfare: reduce technical debt, increase maintainability, etc. Provide a common goal for the “whole team” Prioritize and de-prioritize work

Epic User Stories Epic User Stories capture stakeholder goals for release themes. Epic User Stories fit into releases Will not likely fit in an iteration Team has an idea of how large the effort is Product backlog contains Epic User Stories Create Epic User Stories with Stakeholders This is the product backlog.

Creating User Stories Don’t focus only on the end-user role. Consider other stakeholder types as well. Principals Stakeholders who champion the need for your software and have the authority to acquire and deploy it. End Users Stakeholders who personally interact with your software. Partners Stakeholders who make your product work in real life, such as operations teams and also business partners and system integrators. Insiders Stakeholders within your own organization; such as developers, support engineers, sales, architecture, and marketing teams.

Creating Epic User Stories
Insiders: As a database administrator I can back up a database So that the data can be recovered if a failure occurs.

Insiders: As a developer, I know within 15 minutes whether the new code I checked in is integrated successfully with previous code So that … What is the business value for this user story?

Principals want time to value, return on investment: As a principal, I can have the software deployed and running in production less than one month after purchase, So that …. What is the business value for this user story?

Partners (business partners, support organizations...) As a support engineer, I can easily understand the levels of OS software used so that I can quickly reproduce reported failures, So that …. What is the business value for this user story?

Collaboration Process Exercise

Exercise At your table, pick a product Create Release Themes
Create 2-3 Epic User Stories for the first/next 3 releases

User Story Team Create a User Story Team, including (but not limited to): Product Owner Stakeholders Scrum Master Cross-disciplinary Representatives from the scrum team Technical knowledge required

User Story Team Stakeholders on User Story Team
Represent each important stakeholder type: Principles End Users Partners Insiders If real stakeholders are not available, assign stakeholder champions (team members) Champions get to know the stakeholder, understand their requirements

User Story Team Refer to Mike Cohn’s book for details on how to form a user story team and gather epic stories.

User Story Team Keep team as small as possible… but not too small
Identify team champion to coordinate input Agree on success factors for release Use team to develop the first draft of user stories Use appropriate team members to further re/define stories right before every iteration

Leading Agile Refining User Stories Collaboration Model Collaboration Process

Project Management How Do We Deliver?
Breaking stories into smaller stories How Do We Deliver?

Using User Stories Break Epic User Stories into smaller User Stories
Break Epics for the next one (or two) releases User Stories by definition fit into an iteration User Stories from the Release Backlog Avoid user stories that are too small: When documenting the story takes longer than implementing it Bugs, user interface tweaks, etc.

User Stories Successful iterations have multiple small stories:
Smaller stories can be implemented & tested progressively throughout the iteration Reduces the time between code and test

Who Sizes the Stories? Cross-disciplined scrum team that will deliver the story Stories are sized in "story points" – relative to one another Based on the team’s skills Based on the technology they will use Use “Planning Poker” (next class module) No two scrum teams will size the story the same

Who Sizes the Stories? What if you cannot size a story?
May need more domain knowledge, have more conversations If technology is unknown, use architectural spikes Short (time-bounded) iteration to learn “just enough” to proceed

Break Stories into Smaller Stories

User Stories Recommendation:
Do not maintain a hierarchy of stories under an epic Easier to manage a flat list of user stories Hierarchical stories overcomplicate the backlog Hard to remove smaller stories

Splitting on Operational Boundaries
Search Screen First: Basic User Interface 50% of search fields Parts of query builder that used those fields Message “search found 297 matches” Second: Data display grid Third: Remaining search fields Remainder of query builder Fields Query Builder Complex Data Display Grid Data-base

Splitting into separate CRUD operations
CREATE READ UPDATE DELETE As a technical marketing rep, I can add (create) an orderable part to the online catalog As a technical marketing rep, I can view (read) the list of orderable parts in the online catalog As a technical marketing rep, I can edit (update) an orderable part in the online catalog As a technical marketing rep, I can remove (delete) orderable parts from the online catalog

Remove Cross-Cutting Concerns
Consider creating two versions of the story: One that meets cross-cutting concerns and one that does not. Cross-cutting concerns: Security Logging Error handling Etc.

Attributes of a Good User Story
INVEST ( From Mike Cohn) Attribute Explanation Independent Does not depend on other stories Negotiable Not all details necessary Valuable Has tangible value to stakeholders of the software Estimate-able You can estimate stories via story points Small Fits in an iteration by definition Testable Required to demonstrate that story is “done”

Exercise Break your Epic User Stories for the first release into User Stories. Do they all have the attributes of a good user story (INVEST)?

Leading Agile User Stories Flow Collaboration Model Collaboration Process

Demo Working Code to Stakeholders
Flow: The Big Picture Epics Stories Release Planning Trawl for Requirements Stakeholder Goals Create/size User Stories Release Backlog Epics Stories Iteration Backlog Select High-priority Stories Reflect& Take Action Time Boxed Iteration Get Feedback Refine Stories, Plan Work Scrum Code, Doc & Test Discuss Story Progress Demo Working Code to Stakeholders

Evolutionary Feature Design
Why not stick to well defined features documented in the beginning of the release? Once users see a feature start to work, they better understand how they want to use the feature Feature design & functionality will adapt to what becomes possible in the technology as you use it & learn about it Release priorities, market forces, and stakeholder needs change throughout the life of the product Team members learn from stakeholders as they go This is one of the biggest issues that many waterfall developers have with moving to Agile. It feels easier to implement something that does not change. Feature design has to evolve as you use the technology and learn about it Functionality will have to adapt to what becomes possible in the technology Feature design and functionality will adapt to what you learn about the technology as you use it From Mike Cohns, User Stores, and Kessler, Sweitzer Outside-In Software Development Old sub-bullets In other words they change their minds about what they want once they see it working Assumptions made at the beginning of the development cycle may be jeopardized Plan for this, allow products to evolve as they are developed

Evolutionary Design: How it can work
User Stories Summary Map content released functionality iteratively 1: Input an address and see the location on a street map 2: Input two addresses and get directions between them 3: Change the route by dragging the route to other streets If this feature was fully specified in the beginning, how would it look? How would you specify alternate routes? Using current traffic? Listing the other roads to use? Once you see the route, it seems obvious to want to drag it Lessons? Evolutionary feature design worked Get “enough” functionality out sooner Discover what feature to add next based on feedback The point is you do not have all the features you may want like a route by traffic, a bike-friendly route, comparison of routes, etc. But as you add useful features, the feedback they get will help them determine what to do next. Jun/10

User Stories Overview Basics Creating Refine Flow

Terms Epic User Story User Stories Release Themes Champions
Architecture Spikes

References Agile Project Planning: Writing Good User Stories: User Stories Applied, Mike Cohn

Reflection

Key Characteristics of Successful Agile Projects
Short, Stable, Time-Boxed Iterations Stakeholder Feedback Self-Directed Teams Sustainable Pace Bring the points previously together to review these characteristics… Ask everyone their perspective around iteration (what is it, how long is it) – Ted likes to promote the idea of 2 week iterations but the class may pick a different length. The first two features are critical towards achieving stable consumable code, the last two features focus on developing/identifying how the team works together and in what fashion. You can choose to discuss what the difference is with self-directed vs self-motivated teams? What are the terms and what do they mean. The term self- directed is intended to promote motivation

Project Framework

Project Framework - Iteration Plan
Inception Elaboration Construction Transition Product-ion Architectural “Spikes” Prototyping consumability tasks globalization and translation focus AMDD – Agile Model Driven Development ( integration with other components / products

Framework – Overlapping Releases
Inception Elaboration Construction Transition Product-ion Inception Elaboration Construction

Framework - Overlapping Releases
Inception Elaboration Construction Transition Product-ion Inception Elaboration Warning: Beware of PowerPoint Architects See Andy Hunt and Venkat Sumramaniam’s discussion on PowerPoint architects in Practices of an Agile Developer (Raleigh, NC: Pragmatic Bookshelf, 2006).

Agile Project Management

Similar presentations

Presentation on theme: "Agile Project Management"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Agile Project Management

Similar presentations

Presentation on theme: "Agile Project Management"— Presentation transcript:

Similar presentations

About project

Feedback