PM 201 Scrum Training

Project Management 201: Scrum & Agile Training

John P VajdaProject Manager: PMP, CSM

Agenda

Agile vs. Waterfall The Principles of Agile The Scrum Process The Grocery Analogy

Agile vs. WaterfallAgile vs. Waterfall

Agile vs. Waterfall The facts and figures

Only 42% of requirements are ever implemented 66% of software functionality is rarely used 80% of a system is built after it’s first release Only 16% of projects deliver on Time, on-budget, with all defined scope

Source: Standish Report: 1994

Big Visible Scrum Training: 2009

Agile vs. Waterfall What is Wrong with Waterfall?

Long duration between releases Poor visibility into product and progress Change is expensive and happens late in the cycle Cannot quickly test new ideas Risk increases over time Cannot continuously re-evaluate investments

Agile vs. Waterfall So what can I do differently?

Upfront requirements are wasteful and wrong: learn to work without all the details

Building software that is not used is expensive and wasteful: Don’t waste your time and money

Release earlier and faster! Include your customers into your project team and get real time feedback Embrace uncertainty

Agile vs. Waterfall What is right about Agile/Scrum?

Scrum is an Agile process and is iterative Can deliver the highest business value in the shortest time Can rapidly and repeatedly inspect and adapt Progress is measured in the form of working software Customers can see real progress every 1 to 4 weeks Allows you to actively pursue opportunities to improve

Agile vs. Waterfall A Visual Representation

So this is how it looks…

The Agile Principles

The Agile PrinciplesThe Agile Manifesto Value Statement

Individuals & InteractionsIndividuals & Interactions

Working SoftwareWorking Software

Customer Collaboration

Customer Collaboration

Responding to Change

Responding to Change

over

over

over

over

Process & Tools Process & Tools

Comprehensive DocumentationComprehensive Documentation

Contract NegotiationContract Negotiation

Following a “Plan”Following a “Plan”

The Agile PrinciplesWhat we adhere to and uphold: Agile Manifesto

1. Change is good, welcome change2. Frequent iterative delivery3. Customer collaboration4. It’s about people, get them what they need5. Strive for the highest level of collaboration6. Progress measured as a working product7. Maintain a constant sustainable pace 8. Continuous attention to technical excellence and good design9. Seek the simplest solution 10. Self Organizing Teams11. Continue reflection and improvement

The Agile Principles(M)yths vs. (R)eality

M: Agile is a “Cowboy free-for-all”R: Agile is very rigorous in its principles

M: Agile does not scaleR: Agile has been scaled to hundreds of product developers

M: Agile is not for distributed teamsR: Agile supports the model of multiple distributed teams that adopt the same principals and

practices

M: Agile = “No Documentation”R: Agile stresses “necessary” product documentation

M: Agile ignores architectureR: Agile stresses continuous architecture and design evolution

M: Agile means “No Planning”R: Agile stresses the importance of short-term and long-term planning

The Scrum ProcessThe Scrum Process

The Scrum Process The Project Roadmap

Projects comprise of multiple releases Each release comprises of multiple sprints Stories are started and completed within each sprint Stories are executed based on value and priority Value is set by Product Owners based on business need, cost, ROI, etc

The Scrum Process The Team and the Backlog

Each Team has a ScrumMaster (Team Lead, Project Manager, Iteration Manager)

Each Team has a Product Owner (Product Manager, The Voice, The Business) Each Team works from a Product Backlog Each Team has a customer who can represent the user community The Product Backlog is used to define what will be in each Sprint (iteration) Each Sprint has a Sprint Backlog (iteration backlog)

I am a product owner!

I am a product owner! I am a

ScrumMaster!

I am a ScrumMaster!

We are Developers!

We are Developers!

I am a customer!I am a customer!

The Scrum Process The Product Backlog

Consists of high-level feature requirements, enhancements, etc. Should have rough relative size estimates, not actual estimates Should be prioritized correctly Is expected to change throughout the project Does not need to be perfect or complete A Product Backlog Item (PBI) is also a Story

The Scrum Process The Product Backlog & Stories

Follow the I.N.V.E.S.T Principle when creating a Backlog Item or Story!

The Scrum Process The Product Backlog & Stories

It is really just a prioritized list! Estimating shouldn’t only be time specific. It is good practice to size items by story points or

arbitrary size values, that represent general size and complexity This prevents estimate anchoring and allows the team to not get “hung up” on time Discuss the story and indentify acceptance Criteria to determine when the story is finished

Backlog Item Estimate Priority

As a Conference Room Coordinator I want to allow a Guest to make a reservation in the system so that we can book their request for a conference room in our system.

Large (4 –6) 1

As I Guest I want to cancel a reservation and have it removed from my list of pending conference room bookings so that if my plans change, I can make adjustments on the fly. Small (0-2) 2

As a Guest I want to change dates of a reservation and have the new dates be visible so that if my meeting changes I can see the change dates in my meeting itinerary Med (2-4) 3

The Scrum Process But Why Stories?

Stories shift the focus from written to verbal communication Stories avoid the need to put everything in writing upfront Stories describe relatively small pieces of functionality that delivers business

value Stories are better suited for planning purposes Stories are written in business language so users can understand and

prioritize them Stories avoid implementation detail or trying to provide a “technical solution” Avoiding putting time on a story allows the team not get hung up on time Range estimates work best

• Small: 0 to 2 days

• Medium: 2 – 4 days

• Large: 4 to 6 days

• X-large: 6 to 8 days

• XX-Large: 8 to N Days

The Scrum Process How detailed do stories need to be? Don’t get hung up on details. Stories become more detailed as you move through Sprint Planning

Like a Work Breakdown Structure

The Scrum Process How do I plan my first sprint?

Set a Sprint Duration (1 week to 4 weeks) Plan your Target Velocity or the sustainable throughput of the project team

(“Sustainable throughput” is simple the amount of backlog stories the team can successfully complete in each sprint)

Use the Product Backlog and the sized stories to determine your sprint plan The team will need to commit to the amount of stories they can complete in the first

sprint

In this example, the team

committed to 485 hours

for Sprint #1

Now we know our Target Velocity!

The Scrum Process More on Sprint Planning

The Scrum Process We are Sprinting! Now What?

Now it’s time to work as a true Scrum team!

The Scrum Process More on the 15 Minute Daily Scrum

Is 15 minutes enough? Why everyday? Can I move this meeting around? What if the team needs more time to collaborate?

The Scrum Process More on Sprint Reviews and Retrospectives

The Scrum Process What about “milestones” during a Sprint?

Scrum doesn’t have" milestones” but things must be done!

1. Sprint Planning Meeting (2 to 8 hours): critical to planning your sprint story work 2. Daily Scrum Meetings: (15 minutes) A daily chance for the team to sync up3. Completion of Stories within the Sprint: the team works together to complete

the stories completely! 4. Functional Demo and Sprint Review: You need to show your completed software

to your customers for approval and feedback5. Sprint Retrospective: A mini Lessons Learned, what went wrong, what went right6. Review of the Product Backlog: What has been done, what has to be added from

the Sprint Backlog, what are our new priorities?

Then it starts all over again…..

The Scrum Process How many stories I can complete in the next Sprint?

Measure you velocity of the team after the Sprint This is easy to measure by looking at the “burn down rate” of the team (by days, story points,

etc) Now just fill your Sprint with the right amount of stories based on your velocity. Remember, the team has to agree to do the work! Always plan a few extra stories as “bonus stories” if you have extra time

The Burn Down

• Work that is completed is track against remaining days of the sprint

• The target line indicates the velocity the team should track to during a sprint

• Points above the line indicate work trending slower, points below the line indicates work trending faster

• As you complete your work you should trend downward to 0 hours of work on the last day of the Sprint

The Scrum Process

From Release Planning to the Daily Scrum: A Recap Each team plans, sizes, manages and executes on its Product Backlog The Backlog is an ongoing “living” list and needs constant attention Value assessment, ROI, and prioritization is key! Each Project Starts with High Level Release Planning ( ~3 months out) Each Sprint starts with Sprint Planning ( 1 week to 1 month out) The team meets in daily scrum meetings (15 minutes sync ups)

The Scrum Process What if the work isn’t a story?

Sometimes the work you do on a project won’t really add value to the business and isn’t functional. Examples of this include team training, infrastructure set up, installation of products, etc.

Scrum uses several different terms and processes to handle these types of scenarios Sprint 0: To “setup” a project or product, to do non-functional work

The Scrum Process What if this non-functional work comes during a Sprint?

In Scrum you can create stories that are considered Spikes Spikes would be tasks in a sprint that aren’t functional and don’t add direct

business value Spikes should be time boxed, and won’t deliver any real business value Depending on how you measure velocity, (by story value points vs. time) this

may impact your sprint velocity. Spikes would include product training, ordering hardware, installing

components, seminars, etc.

The Scrum Process This is fast, how do I continue to do good work?

How we do it:

Requirement are stated as series of tests which allows for Test Driven Development Developers can then design and build product to pass tests This reduces probability and severity of future defects This provides testers opportunity to conduct exploratory testing Allows for work to be “sequential” – but all activities occur all the time (Agile) We continuously integrate We pay close attention to technical details and good code writing We keep our technical debt low (time consuming mistakes or assumptions) You do not need to finish one type of activity before moving on, which means no

bottlenecks

•In order to embed quality we need a single process flow!

The Scrum Process More on Test Driven Development

• Automation of Tests and Continuous integration of code is key!

The Scrum Process What else do I need to know?

The Team only works on one Sprint at a time Once the Sprint is agreed to, the stories cannot change. New stories would be vetting against the product backlog and executed in future sprints A Sprint should never be extended! You must complete as many stories as possible, and move onto the next

sprint, reprioritizing your backlog with the unfinished stories and plan your next sprint Focus on completing features and functionality, not tasks! There is truly no “I” in a Scrum Team Prioritization is key, it’s the Product Owners job to define priority It’s the Scrum Masters job to keep everyone working together Scrum meetings start on time, and do not move! Everyone should attend these meetings A Sprint has a Sprint Backlog, this feeds the Product Backlog

The Grocery Analogy

The Grocery AnalogyAgile & Scrum happen everyday

You make a list of groceries: “Product Backlog” You think about what you want to eat that week, Maybe you will make spaghetti 1 night,

hamburgers the next etc: “Stories” Your prioritize this list based on your budget, what you need what your family wants to eat,

planned dinners for the week:: “Product Backlog Prioritization” You don’t try to plan for 6 months of groceries, you maybe plan 1 or 2 weeks in advance: “Sprint

Planning” You finalized your list and head to the store to buy your items: " Completion of Stories” You check that you’ve gotten everything on your list and get feedback from your family on your

purchases: “Sprint Review” If your forget something, made a bad dinner, etc. you move the item to next week’s list, or plan

on not making that again: “Re-prioritization and Review of the Backlog” You tell yourself you won’t forget the item next week and write it in bold letters on the list, you

never make that “bad” dinner again: “Sprint Retrospective”

<Insert Picture Here>

Thank You!

•A majority of this information was taken from the Big Visible CSM training documentation. Big Visible was kind to share and approve the use of this information.

•For more information on Big Visible and their training, see their website: http://www.bigvisible.com/