1

Agile (SCRUM): Basics & Adaption

Prepared by Helen Ioffe

2

Table of Content

• Introduction to Agile Principle• SCRUM roles • Scrum Meetings • Product Backlog• Estimating with Scrum: Product Backlog Estimate• Sprint Backlog and Burndown chart• Estimating with Scrum: Sprint Backlog• Sprint Review / Retrospective• Agile Product Management• Transition to Agile discussion

3

Overview: Agile with Scrum• Agile principles:

– Deliver working software– Deliver working software frequently– Welcome Change– Self Organizing Teams– Reflect regularly on process and product

• Various Agile Methodologies currently adapted – XP (Extreme Programming)– Kanban– FDD– SCRUM (some say that 50% of software development groups utilize this approach)

• Basic Definition of SCRUM– A key principle of SCRUM is its recognition that during a project customers can change their mind

very often (requirements churn). Therefore, SCRUM adapts and empirical approach accepting that the problem cannot be fully understood or defined, focusing instead of maximizing the team’s ability to deliver quickly and respond to emerging requirements.

– Iterative, incremental framework for managing complex work (such as new development)– Although developed for management of new development, it can be used for management of

maintenance team as well ad distributed team or as a general project/program management approach

• SCRUM is about “self-organizing” teams• Yes, SCRUM uses whiteboards and yellow sticky notes DAILY

4

Why use SCRUM• Allows to deliver the highest business value features first and will avoid building features that will never

be used by the customers.– Since industry data shows that half of the software features developed are never used, development can be

completed in half the time by avoiding waste, or unnecessary work.

• Allows for impediments resolution as soon as they are raised– Most of the time development is slowed down by issues / impediments addressed during status meeting. – With SCRUM, these impediments are prioritized and systematically removed increasing productivity and quality.

• Removes management pressure from the teams. – Teams are allowed to select their own work, then self-organize through close communication and mutual agreement

on how to best complete the work.

• Allow better tracking and quality delivery due to completion of short development increments where changes are incorporated during the implementation process and not after the development

• Some known statistics:– Agile projects are 50% faster to market– Agile projects are 25% more productive with ¼ the defects – ROI improvements >4x

• History of Scrum– Scrum is a “lean” approach to software development. – The term came from 1986 study by Takeuchi and Nonaka.

– They wrote that projects using small, cross-functional teams historically produce the best results. – Scrum is a simple framework used to organize teams and get work done more productively with higher quality.

– It allows teams to choose the amount of work to be done and decide how to best to do it.

5

Overview: Main Characteristics of SCRUM• 2-4 weeks (no more) Development “Sprints”

– It is started with 4 weeks, but recently 2 weeks sprints are most commonly used• Each “Sprint” must produce a potentially shippable product and pass Acceptance review by

the Product owner– Each “Sprint” should include QA cycle and be (end-to-end solution) that can be demonstrated to a Product Owner

• A roll up of “Sprints” can be planned as a release• Product backlog DOES NOT change during each Sprint.

– Hence, another reason why Sprint cycles are short

• The Set of feature that go into a “Sprint” should come from Product Backlog– Product Owner is a key person who prioritizes the backlog

• Self-Organizing Teams– SCRUM enables creating of self-organizing teams by encouraging collocation of team members, constant

communication– Teams stay for long time to increase “Velocity” and hence productivity– No Leads– Team Commits to each sprint

• Chicken & Pig Story– A pig and a chicken are walking down a road. The chicken looks at the pig and says, "Hey, why don't we open a

restaurant?" The pig looks back at the chicken and says, "Good idea, what do you want to call it?" The chicken thinks about it and says, "Why don't we call it 'Ham and Eggs'?" "I don't think so," says the pig, "I'd be committed, but you'd only be involved.“

6

SCRUM Roles• SCRUM is a process with a set of practices and predefined roles:

7

“Chicken and Pig” Story applied to SCRUM• “Pig” Roles – commitment based team role:

– Product Owner• The Product Owner represents the voice of the customer. He/she ensures that the

Scrum Team works with the "right things" from a business perspective. The Product Owner writes customer-centric items (typically user stories), prioritizes them and then places them in the product backlog

– ScrumMaster (or Facilitator)• Scrum is facilitated by a ScrumMaster, whose primary job is to remove impediments

to the ability of the team to deliver the sprint goal. The ScrumMaster is not the leader of the team (as the team is self-organizing) but acts as a buffer between the team and any distracting influences

– TEAM• The team has the responsibility to deliver the product. A team is typically made up

of 5–9 people with cross-functional skills who do the actual work (design, develop, test, technical communication, etc.).

• “Chicken” Roles – involvement based role:– Stakeholders (customers, vendors)– Managers

8

SCRUM Meetings: 1.Daily Scrum• Daily SCRUM –

– NOT A STATUS MEETING !!!!!!!!! The goal of Daily scrum is to Synchronize TEAM members– Must be Stand Up (to limit time) – with a rigid/fixed structure

• Stand up must be next to visual progress artifacts – such as BurnDown Chart or Sprint Backlog.• Every body must be present. If somebody can’t attend, another team member should report of that person progress.

– No more than 15 min– Any issues – “use 16th minute” rule– All are welcome but only “pigs” speak– Same time / location each day

• During the meeting each member answers 3 questions with last 2 being most important:– What I did yesterday– What I will do today – What impediments I had from being more productive (resolution of impediments should occur outside of SCRUM )

• Common problem – “I know what I need to do and I don’t need to waist time in daily meetings”. “ I can work with my team

member”• Solution: SCRUM is a team based approach to development. The whole team either succeeds of fails the each Sprint

(based on acceptance of each sprint). • Each team member will get to know / gets to hear project progress and impediments.

– “Meetings are only to learn the status of the project• Daily SCRUM is not a status, but a work meeting to deviate the work needed for today between team members

• Tips on how to manage Daily Scrum to be no more than 15 min a day– “Yellow Card” offenders (team member who would go on & On)– Stand Up (all) – remote teams should stand too.

9

SCRUM Meetings: 2. Scrum of Scrums• The goal is to allow multiple teams to discuss their work, focusing on areas

of overlap and integration –– Run this on a predefined basis for large project with multiple project teams or when

multiple parallel efforts are ongoing (as in our case).– Also timeboxed meeting – 15 min (if possible) but could be extended once a while

depending on the number of teams representative that are participating. – IT IS a meeting to address the problems as it could affect multiple teams

• A designated person from each team attends– Usually a contributing team member rather than a Scrum Master or a Product Owner.– Attendees could be rotated if needed– Frequency should be determine by the teams (suggested daily but not necessary – but

could be conducted a couple of times a week)

• The agenda is similar to Daily Scrum:– What has your team done since we last met?– What will your team do before we meet again?– Is anything slowing your team or getting in their way?– Are you about to put something in another team’s way?

10

SCRUM Meetings Continue• (3) Spring Planning Meeting:

– Occurs at the beginning of each Sprint cycle – every 2-4 weeks– Goal of this meeting is to select what work is to be done– Prepare the Spring Backlog that details the time it will take to do the sprint– Identify how much work is likely to be done during the current sprint– No more than 8 hours.

• (4) Sprint Review Meeting:– Review the work that has completed and not completed– Present the completed work (aka “The Demo”) to Product Owner/Stakeholder

• At this meeting the Sprint either successful or had failed as a whole• In case of failure, the items go back to the Product Backlog and included in the next Sprint (Per Product Owner

priority)

– Incomplete work cannot be demonstrated• That means that the Demo must pass QA, and be in the QA environment. • Remaining incomplete work goes back to Product Backlog

– No more than 4 hours

11

Product Backlog• Product Backlog – master list of desired functionality.

– Product backlog is prioritized by Product Owner• Product Backlog is used to pull functionality and create sprints

– Product Backlog includes functional and non-functional requirements• When project is initiated there is no comprehensive estimates to write down.

– The product owners shows up at the Sprint Planning Meeting.– The team moves items from Product backlog into Sprint Backlog.– During Sprint commitment, Product Owner commits that he/she will not throw new

requirements at the team during each sprint. • Product backlog is allowed to grow and change as the project progressing but

continuously gets prioritized by Product Owner. – Changes to backlog is often encouraged but for items outside of the sprint.

• Product backlog items can be technical tasks (i.e. “Refactor Login to throw exception”) or User Specific features

• Product backlog items have very high level SWAG (see example)• Backlog consists of Item description and a short “User Story” that describes the

item.

12

Product Backlog Example

Product Backlog Sample

Priority Item# Product Name Function Full DescriptionRelative Estimate

Raw Estimate

Reamaining Hours by Sprint

High 1 FraudGUARD PDF generationUser Story goes

here 2 25hr 25 10

Medium

2 DISSCO PDF generationUser Story goes

here 13 100hrs

3 FraudGUARD ScoringUser Story goes

here 8 75hrs

Low 4 Preffis Plus ScoringUser Story goes

here 5 50hrs

•Product Backlog TIPS:• Functional dependencies are handled by sorting dependent items as lower

priority• It includes “non-functional” value – as the system will not be usable if these

items are not fulfilled.

13

Estimating with SCRUM• First, Product Backlog needs to be estimated. For this, the high level estimates are usually

provided in order to get the size of items in the backlog.– Planning Poker – is a technique often used with Scrum teams. It is a process of estimating

product backlog in points not in units of time. Here is how it works:• Usually it is estimated in points using for example Fibonacci numbering sequence (1,2,3,5,8,13,21..) *

each number is the sum of previous two. • It is based on a relative size of one task to another and is not precise. * clearly “21” is a lot bigger than “2”

• It answers the question “How big is IT ?” and NOT “How long will IT take?”• The backlog is sized by Scrum TEAM

• How does “Planning Poker” estimation work?– Team agrees on what “1” value is (the smallest “story”)– For each of the 5 highest ranking stories

• Product Owner is present to answer questions / details of what this enhancement is• Scrum Master facilitates discussion and calls for the vote on the size after e.g 5 min• Each team member puts their card out with a relative number written down• Team members with Highest and smallest estimates would need to explain the assumptions –

timeboxed to 5 min• Team votes again. • Scrum Master marks the Point Value

• Once backlog is sized, Product Owner can set the priorities for items in backlog– Product Owner can re-ranked the backlog items based on their size.

14

Estimating with SCRUM• Once Product Backlog is sized, the next step is to

define the tasks for the Sprint. • This is done during Sprint Planning Meeting (see

description on slide 8)

• Team creates sprint tasks in a Sprint Backlog• Scrum Master manages this process• Team signs up for tasks, they are NOT assigned by

Scrum Master• Estimated work is entered in the Sprint Backlog• Any team member can add, delete or change tasks

(content, estimates, sign-up) in the sprint backlog during the Sprint.

15

Sprint Backlog• Sprint Backlog – is a list of tasks that is derived from Product Backlog (basically the work that needs to be done to finish User Stories reported in Product Backlog. • Sprint Backlog is a tracking mechanism to see the progress at any given point• Scrum team is committing that they will complete its current sprint. • Each Sprint either a success (if passes acceptance by Product Owner) or fail•The Team CAN add new items to Sprint as part of discovery or items can be dropped (see example above). There is no priority in tasks to work on just the priority of Product Backlog• Product owner does not add requirements to any current (committed) Sprint but rather to Product Backlog. If urgency arrives, sprint is cancelled and another one is created with additional items from Product backlog• Number of completed sprints is used for Sr. Management reports to track project progress at any given point•Common Problems:• “Integration is painful”

Answer: do it more often until you become so good at is that is not painful• “We’re having trouble delivering finished software in two weeks.”

Answer: Try one week iterations until you’ve mastered that

16

Sprint Backlog / Burndown chart

17

Burndown chart

• Burndown Chart – uses to demonstrate remaining work in the sprint and allows project manager to report effectively on how much work is left to do, and estimate final project completion based on the current product backlog and estimate. The Burndown chart is a plot of hours remaining on the project versus time.• Good Sprint Practice – no more than 2 pen tasks per Person• Team selects items for sprint backlog, sizes them and commits• Scrum Master maintains the sprint backlog and publishes burndown chart to reflect the progress

18

Burndown charts: How to read them•This is how Ideal Burndown chart should look like. This also indicates a level of velocity i.e. that the work is performed at a steady rate.

•This burndown chart represents that the progress is being made, however, by no means fast enough.

•This demonstrates that the work was done too fast – not enough work in the sprint.

19

Sprint Review and Retrospective Details • Sprint Review - Each Sprint ends with Sprint review where Scrum team

demonstrates what was accomplished during the sprint– This is also known as feature demo. The team is looking forward for the following

feedback:• Have we completed enough requirements• Have we understood the requirements and translated them to working feature

– Product Owner, Scrum team, Scrum master, management, stakeholders are invited– It must be a working, shippable solution that works in integrated environment (i.e in

QA) and that has already been tested prior to review– Functionality that is “not done” cannot be presented in PPT slides. – It starts with presentation of sprint goals – which must be measurable for ease of

demonstration– Sprint Review ends with Scrum Master discussing next sprint review

• Sprint Retrospective– It is timeboxed to 3 hours. The goal is to improve the process with the next sprint– It is attended only by the team, the scrum master, and the product owner.– The following questions are answered:

• What went well during the sprint• What could be improved in the next sprint

20

Estimating with SCRUM during Sprint

• Use Velocity in addition to Burndown charts and sprint estimates• Velocity is how much product backlog effort can be handled in one sprint.

– This can be estimated by viewing previous sprints, assuming the team composition and sprint duration are kept constant.

– You can establish velocity on a sprint-by-sprint basis if we use “commitment-based” planning

– Velocity is calculated not as a % complete of user stories but in story points completed from product backlog

– The large the velocity, the greater the progress.

• Once velocity is established – it is a tool that can be used to plan projects and forecast release and project completion dates.

• To start estimating velocity we need– 1) Estimate team size for the release– 2) Decide on sprint duration (i.e. 2 or 4 weeks)– 3) Decide on how many initial user stories could reasonably be achieved in the Sprint. – 4) Add up the story point (based on estimation)– Divide the Product backlog into Sprints to predict release and come up with a release

plan

21

Agile view of Product Management• Agile view of Product Management is that Business drives

development• Maintaining a healthy backlog is a key to supporting business needs

– Highest Priority items should be very specific and small in size– Items are in priority order and can be re-prioritized at any time– Items in Product Backlog can be split at any time– Items can be removed at any time– The lower the priority the large / general the backlog items are

• Challenges to “healthy” product backlog – are multiple lists– “Bugs to fix”– “Technical backlog” (non-functional issues)– Unfinished Product (phase 1 feature set, Phase 2….)– One of the solutions is to create a single prioritized list of work

• With potentially shippable product increments (sprints)– Single Prioritized List

22

Agile view of Product Management• How to avoid problems when cannot prioritize “features” vs “bugs” vs “Technical Items – so the

agreement on the priority can be reached?– Solution: Create “relative” priority

• Features: As a <user> I want to <goal> so that I can know when to do <task>• Bugs: As a <user> I want to <goal> so that customer service / Ams receives 20 calls less each day• Technical Items: As a <user> I want to <goal> so that 10 K concurrent users requests are handled. • In other words, express each item in the log in terms of business value.

– Once this is done – getting agreement from the Product group by placing user story cards on a wall and vote for each items – item with most votes gets the highest priority

• How to avoid problems when there are too many items in backlog?– Possible cause: (1) Bugs or unfinished tasks during sprint or (2) over specification– Solution #1: If part of the story is not done, then the entire story is not done. In this case, if there are unfinished

tasks or bug associated with a story it must be finished or the entire backlog items needs to be prioritized. – Solution#2: convert requirements doc (FSD) into backlog line for line makes a very large backlog. Business analyst

need not create more documents but rather create team understanding

• How to avoid problems when the backlog items are too large and there is not enough information to begin development?– Possible cause: (1) Difficulty splitting larger user stories, (2) user stories are split along process line: i.e. design, code,

test, document, OR split across architecture lines (i.e. database, business tier, UI), OR (3) The “big picture” of the original story is lost, OR (4) individual stories no longer have clear customer value.

– Solution: Use “special-purpose” story types 9i.e. “Spike aka POC” which translates to unable to estimate a user story effectively. Have clear “acceptance” criteria regarding whether or not the “right” thing is built, continue “grooming” your backlog.

• Team invests 5—15% of their time / working capacity with the Product Owner to prepare for the next Sprint– Therefore, the team has to meet with Product owner 1-2 days before the end of current Sprint to discuss next sprint– Acceptance criteria must be reviewed / adjusted– Split Stories if needed / Re-prioritize if needed.

23

Summary for Healthy Backlog• Have a single product backlog• Stack-ranked prioritized list– Use User Stories to compare by business value– Product Owner has final say on Priority

• Keep product backlog reasonably sized– Put unfinished stories back on the backlog– Don’t over specify low-priority items

• Groom the backlog before Sprint Planning– Split large user stories along business value lines– Stories must have acceptance criteria

24

Project Reporting with Agile• One area agile methods don’t really address is project status reporting

– Obviously the daily scrum is a good form of team reporting, but it is really not good for other stakeholders that can’t get to the same scrum each day

– Senior Management still relies on traditional project reporting• Some Reporting solution that help with Project Progress Status

– # of Sprints completed for any given projects– # of Sprints accepted by Product Owner– Burndown charts

• The burndown chart can be calculated using the entire product backlog for the project, not just current sprint • It gives a great indication of the current status and provides good definition of done

– Forecast Future Velocity for any project. • Frequent risk and mitigation plans are developed by the development team itself• Frequent sprints provide transparency on the project progress• Scrum

– has frequent intermediate deliveries with working functionality. This enables the customer to get working software earlier and enables the project to change its requirements according to changing needs

• PMO reports on Release Sprints as part of Release Planning– While software release may have multiple sprints, the release planning is about what will be included

in the next release to production. – If the product backlog is in place with estimated user stories (aka requirements) and the team Velocity

is known, the Team Velocity can be used to divide the Product backlog into Sprints

25

Agile Project Management• Adaption of Agile can be painful

– Looking across project portfolio, there are often project that are other late or over budget, or deliver low value proposition to the customers

– Agile will cause increased resource contention and misalignment with typical PMO metrics and audit points (such as fixed delivery dates, project plan estimated progress, project cost actual vs estimate)

– Traditional portfolio management utilizes techniques that are targeted to start as many project as possible with utilization of individual resources.

• Focus of Agile PMO– Always focus on the highest priority items

• Agile PMO group must ensure that product backlog is reviewed regularly and groomed

– Maximize project delivery speed• Put less emphasis on traditional progress metrics, such as individual resource allocation • In Agile, the PMO can only start as many projects as there are available teams where each team is fully cross-functional from

business analyst to quality assurance. • Projects are then pulled from the prioritized project backlog of selected projects and allocated to the appropriate teams• In Agile, the PMO group can work with business and other groups to purge “sick” projects, which will help in redirecting team

members efforts to more productive projects

– Manage System Constraints (aka bottlenecks) • Another area not addressed by Agile some key project aspects such as project initiation, cost

management, risk management– Solution could be to augment agile with traditional project management methods where needed

• For example, if we need to product documentation (such as technical design or test plans, they should be part of the any given sprint)

• Another example, if we need to have UI / Design prior to the start of the sprint, the Design team can be part of the earlier sprint (i.e. run 1 sprint ahead) before the sprint team begins implementation of the new design.

– Risk management must be shared by all involved

26

Transition to Agile • Fear of adapting agile practices:

– Fear #1: “Agile can’t give me a firm end date and a commitment to what will be in the product”. Our projects are often tend to be “fixed-in-date” or “fixed-in-scope”• The reality is that, it is always impossible to know (for sure) both the scope an the date for the project – we can only

provide a “best guess estimate”. Estimates often entail large padding or delivery of too little in terms of functionality – “dropped scope” or “schedule overrun”

– Fear #2: “Agile requires QA to be involved in testing right from start as part of Sprint. Often, they are tied up on other projects”• Agile goal is not to solve the problem, but rather expose it and allow the company to properly mitigate it and thus improve

the product output• Options could range from the whole team picking up the lack of QA or move small QA team to be dedicated to work on

Agile style projects

– Fear#3: Agile puts lot of emphasis on automated testing and unit testing, and we have not made automated testing a priority• Agile without a lot of automated tests in place

– 2 most important agile principle: (1) Inspect and Adapt, (2) Iterate (and do it again and again)– The goal is to finish iteration with less manual testing than we started (i.e. automate “easy-hanging fruits first”– All new feature should come with automated tests (that should be part of sprint)

– Fear#4: How would this process work with distributed teams? Self-organizing teams work differently in different countries• Self-organization relies on Container (in which to organize), Differences (among people), transforming Exchanges –

regardless of country. • Cultural differences will influence but not prevent self-organization and the process of execution.

• We can adapt the new methodology while running two options side by side (or implement it based on project)

27

Transition to Agile • We can adapt the new methodology while running two options side by side (or implement it

based on project)• The transition process must be concurrent with changes in development process

– Move to self-organizing teams

• Starting Options:– Setting up Technical practices to be Agile first

• Benefits: quick transition, • Usually happens when team have solid technical background• Drawback: team resistance could be in place, outside coaching might be needed.

– Setting up Requirements to be Agile first• Benefit: Starting with agile requirements makes it hard to avoid being agile later• Useful when: There is a general agreement on what to build• Drawback: Starting this process could take longer

– All In• Benefit: It’s over quickly, there is no organizational disagreement from using two processes at once• Useful when the time is critical, medium size development team. • Drawback: Risky, Costly, may require organizational changes.

• Overcoming resistance tips:– Sell the problem, not the solution

• No one wants a solution to a problem they don’t (think they) have• Adjust the method to fit the company needs

– Put team members in touch with customers• Let the team hear the problems

– Emphasize benefits of the change

28

Transition to Agile

29

Transition to Agile Transition to Automated Testing: Tracking