4/19/2012 1

Agile Product Management &

Development in a nut shell

―Where common sense prevails, so shall Agile‖

Ashwinee Kumar

6 Jan 2012

* I have used ideas, & content from other resources in this presentation.

4/19/2012 2

Agenda

• Agile Manifesto

• Types of Agile

• Best practices of Agile

• Scrum • Documentation

• Sprint details

• User Stories

• Planning & Estimations

• Metrics

• Product Backlog

• Appendix • Best Practices of Distributed Scrum

• Non-functional Requirements

• Product Requirement Document

• Product Vision

• Benefits to Marketing & Sales

4/19/2012 3

Realities of Projects

• Requirements/scope changes frequently due to factors beyond our control

• Defects are expensive – Defect found during test phase could cost 10–15 times more than if found and fixed during

implementation phase.

– Fixing defects in the field can cost 10–100 times more than fixing the same defect in the

coding phase

• 20% of your features will give 80% of a product’s value

• Artifacts such as Detailed design, Requirement document do not add value

to the product

• Features not meeting customer expectation leaves him dissatisfied,

irrespective of what is in the contract

4/19/2012 4

Agile Manifesto

• Individuals and interactions over processes and tools

• Evolving - Working software over comprehensive documentation

• Collaborative - Customer collaboration over contract negotiation

• Adaptive - Responding to change over following a plan

4/19/2012 5

Types of Agile

• Lean Software Development – evolved from the ideas of lean manufacturing in automotive industry

– includes thoughts on eliminating waste, adding customer value, and empowering workers.

• The Agile Unified Process combines a process with tools and is a derivate of

Rational’s Unified Process.

• Test Driven Development emphasizes the definition of test cases even prior to the

actual implementation of the code.

• Extreme Programming is a toolbox of engineering practices like pair programming, or

continuous integration

• Scrum is an extremely efficient and streamlined process of managing and tracking

teams.

4/19/2012 6

Best Practices of Agile

• Search for the root cause of failure

• Focus on the customer value and avoid any waste

• Decentralize responsibility and accountability

• Focus on teaming and collaboration rather than splitting work

• Continuous improvement (Kaizen)

• Flexibility to react to changing customer requirements

• Standardization of processes

• Planning and anticipatory thinking

• Simple and pragmatic tools

4/19/2012 7

Scrum

• Roles - Product owner (play customer), team (implement), scrum master (manage

project)

• Teams – Cross functional

– entrust individual teams with entire end-to-end tasks

• Documents - product backlog, sprint backlog, sprint result, stories, test cases, user

documentation

• Sprints are broken into stories, stories are broken into tasks

• Large, loosely defined stories are known as epics. Epics are broken into stories in

product backlog

• Tasks can be bug fixes, Features are user stories

• Sprint size - 2 weeks

• Meetings - Sprint planning, daily scrum meeting, sprint review, scrum of scrum

• Tracking – Burn down chart

• A task or a user story is only counted as complete if it is completely done

– including automated test cases, all tests executed, all documentation done, and all remaining

defects fixed

4/19/2012 8

Documentation in Scrum

• Backlog lists and team charters will provide a prioritized list of use cases that are to

be delivered.

• Continuously updated burn down charts provide data to assess the project status and

help to uncover risks and delays.

• Defect documentation keeps a record of bugs that are being resolved

• Design documents share architectural decisions and technical details with a larger

community and are an excellent source of information for those who will use the

resulting implementation.

• Coding guidelines are useful to achieve a common programming model. They will

help to write consistent code that considers aspects like accessibility, translation,

performance, etc.

• Specifications describe programming interfaces and are needed if other teams will re-

use code provided as a common component.

• Test scenarios describe test cases to be executed.

• Checklists include a lot of know-how that was gained in the past. It absolutely makes

sense to leverage them to make sure that nothing has been forgotten.

4/19/2012 9

Sprint/Iteration

• The idea of iterations is to create an even and steady rhythm of progress in a sustainable, constant pace –

repetitively and predictably

• Development proceeds by designing and implementing small chunks of code, which are immediately tested and

continuously integrated into the code base, without lag time in between

• All teams and their daily work are synchronized in the common schedule of iterations – the heartbeat of the project

• Sprint Length

– thirty days for a "traditional" software product

– two weeks for a fast moving web service

– weekly iterations might be appropriate for an early stage product, or for delivering rapid fixes on a project

that has a frustrated customer base and/or is in jeopardy of being cancelled.

– iteration cycles longer than four weeks risk behaving like traditional software projects.

•Continuous iterative and adaptive planning

•Continuous design

•Continuous testing (automated)

•Continuous listening

•Continuous conversation and collaboration

•Continuous demos

•Continuous consumption of our own output

•Continuous status

•Continuous feedback

•Continuous learning

•Continuous progress

Iteration 0 Iteration 2

Iteration Test 1 Iteration Test 2

… Iteration n

… Iteration Test n

Function and System Verification

Translation Test

Final Functional &

System Regression

Performance Testing

4/20/2012 10

Sprint/Iteration

• Company Vision -> Product Visions -> Product Strategy-> Release Plan -> Product Requirement

Document (PRDs) -> Product Backlog -> Iteration Backlog -> Epic -> User Stories -> Tasks

• As the goal is to have a customer-ready deliverable at the end of each iteration, it is paramount to

have all the user stories of an iteration completed at the end of that iteration

• Get together with the project sponsor and create a joint vision for the project

• Write the resulting requirements into user stories that should on the one hand be complete but

also as simple as possible

• Acceptance test criteria should be defined for each story before the sprint to allow a clean sprint

exit

• The Sprint Fest is organized as an event in which all development teams give a demo of the use

case they have implemented in the most recent iteration

– Participants - entire team, including testers, product management, executive management,

and -if possible- customers as well

– Respective stakeholders get first hand information on the project progress

4/19/2012 11

User Stories

• Story has to be INVEST

– Independent - Avoid dependencies between stories

– Negotiable - They are not a command. Open to alternatives that might work better and/or require less effort

– Valuable—Always demonstrate why the story is worth implementing

– Estimable—The story should be small enough and contain enough detail that the development team can

estimate the effort.

– Small—A story should represent between a half-day and two weeks. Should fit into an iteration

– Testable—Acceptance criteria for the story should be able to be tested

• Each user story is now broken into tasks. These tasks are sized(and estimated) and assigned to

team members

• MMF (Minimal Marketable Feature) is a good way to start the story. MMF is normally an epic.

• Non-functional requirements (QOS) are written on the User Story as a constraint

– PAPRMIC - Performance, Accuracy, Portability, Reusability, Maintainability, Interoperability, Capacity

Sample User Story

As an end user, I would like to calculate the value my

stocks based on the real-time value at the Stock Exchange

so I can see the accumulated loss or gain.

Sample Tasks

- Write test cases

- Integrate into test framework

- Get all stocks

- Get the current value

- Get exchange rates

- Calculate value

- Handle exceptions

Sample NFR

As a customer, I'd like to be able to use the browser of my

choice so I don't have to download a new browser.

Sample Constraint

The application shall run on Internet Explorer 7.x and

higher, Firefox 3.x and higher, and Safari 4.x and higher.

4/19/2012 12

User Story Estimation – Ideal Days

• Ideal time is:

– The time it takes you to completely finish the user story or tasks.

– The time required to complete design, coding, automated test cases, testing, and

documentation and everything else the task requires.

– The time needed for just doing the work, without breaks, meetings, emails, other parallel

activities, colleagues asking you for advice, and all the other things that usually stop you from

completing the task.

• Ways to estimate

– Planning Poker

– Estimate by Analogy

4/19/2012 13

Metrics for Scrum Projects

• In a project, there should be a clear separation between

Defects: Something that prevents the product from functioning as specified.

Features: New functionality that is either in addition to what the product provides so

far or a change of behavior.

Refactoring needs: The program works as designed, but there are things that the

team wants to improve, for example to improve the maintainability or to remove

unused code.

4/20/2012 14

Product Backlog

High priority, high level of detail

Low priority, low level of detail

Pick the highest priority work item

Add

Remove

Reprioritize

4/20/2012 15

Adopting Agile

Development Effort

Defect Backlog

Testing Effort

Project Start Project End

Open Defects

Development Effort

Defect Backlog

Testing Effort

Project Start Project End

•Huge efforts in development during first half

•Huge efforts in testing and defect fixing during second

half

•Large number of open defects towards the end

•No scope for significant scope changes during second

half

•Development, testing, defect fixing efforts evenly

distributed

•Small number of open defects towards the end

•Scope changes possible any time

Waterfall Model

Agile Model

4/20/2012 16

Pitfalls

• If team tries to deliver more in haste in an iteration, they can only deliver

less in the next iteration due to the bugs introduced in this iteration

• Agile does not mean NO documentation

• Rushing into implementation before stable design

• Bug fixing is non-productive. Customers pay us for adding feature not for

fixing bugs. Minimizing bugs maximizes time for features

• Jumping to a new functionality without resolving pending quality issues

4/19/2012 17

Nitty-gritty of Sprint

• Throughout the release, the teams maintain their team charter document, which includes the prioritized product

backlog with all use cases they tentatively want to address in the foreseeable future.

• Team elaborate a rough high-level design outlining all items of their focus area .

• Only the current iteration is being precisely planned, confirmed, and detailed into an iteration backlog, which lists

the low-level use case descriptions.

• Iterations are time-boxed. They have a defined start and end date. Usually, all teams operate on the same

iteration schedule.

• The content of each iteration is defined at the beginning of each iteration. A team picks the top use cases from the

prioritized product backlog in their team charter and starts designing and coding those items.

• Large user stories are broken in to into smaller, digestible chunks to ensure that a use case can be implemented

within an iteration.

• The teams continuously integrate their code throughout the iteration, documentation, and automated test cases

into a common code stream. There are daily builds of the entire product. Continuous integration with immediate

testing is done to avoid destabilization.

• Ensuring the stability of each build is everyone’s responsibility. Disruptive changes must be avoided by all means.

Every single developer will plan and perform thorough unit testing and automated regression for the code he is

delivering.

• It is a mandate to focus on any open issues and bugs first, before proceeding with the development of new

functionality

• Functional verification testing is part of the iteration within the team. Only tested and properly working use cases

are accepted as a delivered achievement.

• Performance and documentation are further aspects to be covered within the iteration.

• An ―Sprint Fest‖ is held at the end of each iteration

• Each iteration will be signed-off by the stakeholders, confirming that the delivered use cases are working properly

4/19/2012 18

Appendix A – Best Practices of Distributed Scrum teams

• Each site conducts a local standup in their morning to address immediate issues.

• All teams join a daily teleconference standup, ideally scheduled at a common work time for all. A

video-conference standup is better.

• Each location has a Scrum Master Proxy and a Product Owner Proxy. The proxies synch with

their counterparts regularly and learn to guide their local teams and keep them productive.

• Team members visit other sites to deepen relationships and information exchange.

• VOIP and webcams can go along way to overcoming cultural awkwardness and maintaining a co-

located feel

• Distributed teams also need to implement a collaboration tool to function as a virtual task board.

Eg. Rally Software, VersionOne, Xplanner.org, and Atlassian Jira with the GreenHopper plugin

• The Scrum of Scrums is a meeting of Scrum Masters (or other appropriate leads) from all the

product and shared resource teams. Unlike the Daily Scrum that meets every day, the Scrum of

Scrums is generally held between one and three times a week.

4/19/2012 19

Appendix B – Non-functional Requirement (PAPRMIC)

• Functional Requirement = "what the system will do"

• Non Functional Requirement = "how well the system will do it"

1. Performance: Ninety percent of product searches will return results in less than

three seconds.

2. Accuracy: The software will dynamically generate and adjust reorder points to

provide in stock levels of 98 percent for all standard products while maintaining

less than fourteen days' inventory on hand for 95 percent of all standard

products.

3. Portability: The software shall be designed to be ported to Android.

4. Reusability: The graphics rendering engine will be reusable by our other

applications.

5. Maintainability: Automated unit tests must be written for all new code and be run

after each build.

6. Interoperability: All documents shall be stored in XML.

7. Capacity: The data mart must be able to store one hundred and eighty million per

month for five years) and support the real-time analytics tools.

4/19/2012 20

Appendix C –PRD

1. Project goals—tie project to product strategy with measurable goals, such as market share, revenue, customer

satisfaction, productivity improvement, time to deployment, etc.

2. Timeline—target dates for key milestones.

3. Product Background and scope of release—describe whether this is a new product, next release, or an extension of

an existing product, and if it will complement or replace any existing products.

4. User interface constraint—any standards to which the user interface must comply

5. Compatibility constraint—any external and internal interfaces and backwards compatibility that must be developed or

maintained and may impact on other systems.

6. Scalability—system quality defining user, data volume, or transaction levels.

7. Usability and learnability—system quality definition for ease of use or ease of learning the system for a defined

persona.

8. Performance—system quality defining performance goals.

9. Documentation—any documents that must be created, consumer of documents, and intended use.

10. Security—any security issues that must be accommodated and standards that must be observed.

11. Regulatory—any regulation that must be supported.

12. Manageability—any requirements for customer support, account management, or operations to manage the system

and support customers.

13. Reporting—any new metrics that need to be captured and reported against.

14. International—any issues that must be accommodated to support international markets.

15. Assumptions—any assumption that could impact the project.

16. Open Issues—any unresolved issues that could impact the project.

4/19/2012 21

Appendix D - Product Vision

• Company vision might be: "Helping digital photography enthusiasts fulfill their passion.―

• The product vision, which might be considered the corporate mission (i.e., how we will fulfill the corporate vision)

might be: "The most comprehensive selection of equipment combined with the right advice to guide purchase for

the digital photography enthusiast.―

• This statement says a lot.

– First, we are going to carry a lot of products;

– second, we are targeting hobbyists;

– third, we will be providing advice that goes beyond the typical product catalog.

• As this translates into product trade-offs, we will emphasize making products easy to find and providing guidance

to help customers find the right product for their skill levels and interests.

• This is very different from

– choosing to be the low cost leader,

– choosing to serve the professional photography market,

– choosing to take a more paternalistic approach by carrying a limited set of "best in class" products.

4/19/2012 22

Appendix E – Impact of Agile on Marketing & Sales

• Increased revenue, as a result of capturing more customers sooner

• Lower costs by not over-building the product (ultimately you will realize more value for less

development effort);

• Better resource and prioritization decisions due to faster feedback cycles.

4/20/2012 23

Thank You