Spikes nad SCRUM_Se lect6 btech

What are Spikes

Spike Solutions

• Create spike solutions to figure out answers to tough technical or design problems.

• A spike solution is a very simple program to explore potential solutions. Build a system which only addresses the problem under examination and ignore all other concerns.

• The goal is reducing the risk of a technical problem or increase the reliability of a user story's estimate.

Big Design Up Front (BDUF)

What are the purpose of User Stories…

Purpose

• User Stories are used to create time estimates for the release planning meeting.

• They are also used instead of a large requirements document.• User Stories also drive the creation of the acceptance tests.

What is Planning Feedback Loop

7

The XP Roadmap

9

XP practices—a road map(from www.extremeprogramming.org)

XP emphasizes iteration

11

XP emphasizes iteration

XP emphasizes communication

13

Communication is important

Test-driven development

15

Test-driven development

References/Links

Books • Kent Beck, "Extreme Programming Explained," Addison-Wesley,

2000. • Giancarlo Succi, Michelle Marchesi, "Extreme Programming

Examined," Addison-Wesley, 2001.

Websites • http://www.extremeprogramming.org • http://www.xprogramming.com• http://www.jera.com/techinfo/xpfaq.html• http://www.c2.com/cgi/wiki?ExtremeProgrammingRoadmap• http://ootips.org/xp.html• http://pairprogramming.com/

Effort Distribution in a XP project…

Effort Distribution: Project Management

Effort Distribution: Planning

Effort Distribution: Coding

Effort Distribution: Project Meetings

SCRUM

SCRUM

• SCRUM is an

• Agile Project Management Methodology

• Characteristics of an ‘Agile’ methodology are:

• ADAPTIVE, not PREDICTIVE

• LIGHTWEIGHT, not HEAVYWEIGHT

• DESCRIPTIVE, not PRESCRIPTIVE

SCRUM

• Scrum is a lightweight process that can manage and control software and product development.– It is a Project management process.

• However, instead of promoting the traditional analysis, design, code, test, deploy "waterfall" approach, Scrum embraces iterative and incremental practices.

SCRUM

• Similarly, instead of being "artifact-driven", whereby large requirements documents, analysis specifications, design documents, etc. are created, Scrum requires very few artifacts.

• It concentrates on what’s important: managing a project or writing software that produces business value.

SCRUM

SCRUM has the following ELEMENTS:

• A project team called a SCRUM Team

• A Product Backlog of all known Requirements

• A Sprint Backlog of requirements being worked on

• A period of work referred to as a Sprint

• Daily Stand-up Meetings with the SCRUM Team

• A Burndown Chart to track progress of the Sprint

• An Incremental Delivery at the end of each sprint

A Model of SCRUM

Sprint

Daily SCRUM

Incremental Delivery

Burndown Chart

2 - 4 Weeks

Sprint Backlog

Product Backlog

The SCRUM Team

• Is all the people who will COMMITTED to the delivery of the backlogs

• One role is ‘SCRUM Master’ who is in practice the PM

• Is staffed by PMs, BAs, Developers, Testers, Support – i.e. ALL the typical project staff

Product Backlog

• Contains all the currently known requirements for a product

• Is managed by the Product Owner and can change as needed

Sprint Backlog

• Contains the set of prioritised Product Backlog items that are currently being worked on

• Are not to be changed during the Sprint

Sprint

• Is a fixed period of development and testing

• Results in an incremental delivery of usable product

• Usually lasts 2 to 4 weeks

Daily SCRUM Meeting

• Brief ‘Stand-up’ meeting each morning with SCRUM Team only

• What value did you add yesterday?

• What value will you add today?

• What will stop you making progress?

Burndown chart

• Charts delivery of the Sprint Backlog against Sprint Duration.

• Simple, at-a-glance view of progress showing velocity and traction

• Easy to keep updated

Incremental Delivery

• Output of the Sprint

• Working functionality that can be deployed

• Delivered every 2 to 4 weeks, tested and working

Scrum’s three questions

36

What is Scrum Roles?

• Product Owner• Possibly a Product Manager or Project Sponsor• Marketing• Internal Customer• etc.

• ScrumMaster• Represents management to the project• Typically filled by a Project Manager or Team Leader• Responsible for enacting Scrum values and practices• Main job is to remove impediments and remove any politics

• Project Team• 5-10 members• Cross-functional: QA, Programmers, UI Designers, etc.

Scrum Process Flow

Process Comparison

© 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com

40

The product owner plans the product in layers

41

The product owner plans the product in layers

Product or ProjectWhat business objectives will the product fulfill?

ReleaseHow can we release value incrementally?

What subset of business objectives will each release achieve?

What user constituencies will the release serve?

What general capabilities (big stories) will the release offer?

Release plan

IterationWhat specifically will we build? (user stories)

How will this iteration move us toward release objectives?

Iteration Plan

Story (Backlog Item)What user or stakeholder need will the story serve?

How will it specifically look and behave?

How will I determine if it’s completed?

Story Details

Acceptance Tests

42

The Planning Onion can grow to include product portfolios and business strategy

Product or ProjectWhat business objectives will the product fulfill?

ReleaseHow can we release value incrementally?

What subset of business objectives will each release achieve?

What user constituencies will the release serve?

What general capabilities (big stories) will the release offer?

Release plan

IterationWhat specifically will we build? (user stories)

How will this iteration move us toward release objectives?

Iteration Plan

Story (Backlog Item)What user or stakeholder need will the story serve?

How will it specifically look and behave?

How will I determine if it’s completed?

Story Details

Acceptance Tests

Product or Project

Release

Iteration

Story

43

The Planning Onion can grow to include product portfolios and business strategy

Product or Project

Release

Iteration

Story

44

Product or Project

Release

Iteration

Story

The Planning Onion can grow to include product portfolios and business strategy

Product Portfolio

Business Strategy

45

Pro

duct

Ow

ner

Team

Develo

pm

ent

Team

Design and Coded Features Pass Back and Forth Between Tracks

implement iteration 1 features

•gather user input for iteration 3 features

•design iteration 2 features

•support iteration 1 development

implement iteration 2 featuresfix iteration 1 bugs if any

•gather user input for iteration 4 features

•design iteration 3 features

• support iteration 2 development

•validate iteration 1 features

implement iteration 3 featuresfix iteration 2 bugs if any

•gather user input for iteration 5 features

• design iteration 4 features

• support iteration 3 development

•validate iteration 2 features

•planning•data gathering•design for

iteration 1 features – high technical requirements, low user requirements

•development environment setup

•architectural “spikes”

Sprint 0 Sprint 1 Sprint 2 Sprint 3

feature design

code

d fe

atur

es

time

feature design

+ bugs found in

usability testing

sup

port d

ev

sup

port d

ev

Who uses Scrum?

• Microsoft, Sun, Sammy Studios, Siemens, CNA, State Farm, State Street Bank, Philips, BBC, IBM, SAIC, LMCO, APL, Ariba, Federal Reserve Bank, HP, Motorola, Nokia, TransUnion, IDX, Siemens Medical, Gestalt, Yahoo, Conchango, BMC, Lexis-Nexis, Bently Systems, Bose, CapitalOne,Federal Reserve Bank, ClearChannel, Xerox, Patient Keeper, British Telecom, PayPal, …

What is Scrum process flow

Scrum process flow

PlanningProduct owner and team decide which stories are actually feasible to be moved from the Product backlog to the Sprint backlog.

SprintThe team is left alone to perform the user stories which it has committed itself in the planning meeting. The product owner may attend the “daily scrums” if a granular status update is desired.

ReviewThe team presents its work and verifies what it has done indeed satisfies the utmost desires of the product owner.

User Stories in SCRUM

User Stories

• A user story is a software system requirement formulated as one or two sentences in the everyday language of the user.

• It is written by the Product Owner, with the help of the ScrumMaster and Team, if desired and necessary.

• Once completed, it is put in the Product Backlog and prioritized, by the Product Owner, by its relative placement to other user stories.

• Before a user story is to be implemented, appropriate acceptance criteria must be written to ensure proper testing or otherwise determine whether the goals of the user story have been fulfilled.

• Some formalization finally happens when the developer accepts the user story and the acceptance procedure as his work specific order.

User Stories - structure

User Stories - structure

• Who (user role) – is this a customer, employee, system administrator?

• What (goal) – What is the specific functionality that is to be achieved or developed?

• Why (reason) – Helps the developer to understand the broader scope of the story and eliminate any ambiguities that may arise.

• Putting it all together: As a [user role], I want to [goal], so I can [reason].

• “As a registered user, I want to log in, so I can access subscriber content.”

USER STORIES CHARACTERISTICS – I.N.V.E.S.T.

User Stories – I.N.V.E.S.T.

• Independent - For some systems, it's near impossible to make each feature completely independent. In other solutions, e.g. web sites, it's easier. But it's an important aspiration. User Stories should be as independent as possible.

• Negotiable - User Stories are not a contract. They are not detailed specifications. They are reminders of features for the team to discuss and collaborate to clarify the details near the time of development.

• Valuable - User Stories should be valuable to the user (or owner) of the solution. They should be written in user language. They should be features, not tasks.

• Estimatable - User Stories need to be possible to estimate. They need to provide enough information to estimate, without being too detailed.

• Small - User Stories should be small. Not too small. But not too big.

• Testable - User Stories need to be worded in a way that is testable, i.e. not too subjective and to provide clear details of how the User Story will be tested.

Scrum has been used for:

• Commercial software

• In-house development

• Contract development

• Fixed-price projects

• Financial applications

• ISO 9001-certified applications

• Embedded systems

• 24x7 systems with 99.999% uptime requirements

•Video game development

•life-critical systems

•Satellite-control software

•Websites

•Handheld software

•Mobile phones

•Network switching applications

•Some of the largest applications in use