This presentation covers Scrum for developers, project managers, product managers. Scrum made simple ! Highly appreciate your feedback.

1. Agile Product Management &
Development in a nut shell
―Where common sense prevails, so shall Agile‖
Ashwinee Kumar
6 Jan 2012
4/19/2012 * I have used ideas, & content from other resources in this presentation. 1

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 2

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 3

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 4

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 5

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 6

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 7

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 8

9. Sprint/Iteration
Iteration 0 Iteration 2 … Iteration n •Continuous iterative and adaptive planning
•Continuous design
Iteration Test 1 Iteration Test 2 … Iteration Test n •Continuous testing (automated)
•Continuous listening
Function and System Verification •Continuous conversation and collaboration
•Continuous demos
•Continuous consumption of our own output
Translation Test
•Continuous status
•Continuous feedback
Final Functional &
•Continuous learning
System Regression
•Continuous progress
Performance Testing
• 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.
4/19/2012 9

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/20/2012 10

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
Sample NFR
As an end user, I would like to calculate the value my
As a customer, I'd like to be able to use the browser of my
stocks based on the real-time value at the Stock Exchange
choice so I don't have to download a new browser.
so I can see the accumulated loss or gain.
Sample Constraint
Sample Tasks
The application shall run on Internet Explorer 7.x and
- Write test cases
higher, Firefox 3.x and higher, and Safari 4.x and higher.
- Integrate into test framework
- Get all stocks
- Get the current value
- Get exchange rates
- Calculate value
- Handle exceptions
4/19/2012 11

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 12

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/19/2012 13

14. Product Backlog
Repriori
Add
tize
High priority,
high level of
Remove detail
Low priority,
low level of
detail
Pick the
highest
priority work
item
4/20/2012 14

15. Adopting Agile
Waterfall Model
Development Defect Backlog
Effort •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
Open Defects •No scope for significant scope changes during second
half
Testing Effort
Project Start Project End
Agile Model •Development, testing, defect fixing efforts evenly
distributed
Development
Effort •Small number of open defects towards the end
Defect Backlog •Scope changes possible any time
Testing Effort
Project Start Project End
4/20/2012 15

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/20/2012 16

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 17

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 18

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 19

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 20

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 21

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/19/2012 22

23. Thank You
4/20/2012 23