The Epic Guide to Agile: More Business Value on a Predictable Schedule With Scrum

If agile is so amazing, why is it so hard to produce reliable results?

Most executives, managers, and team members get excited to adopt agile only to see it fall far short of expectations. This 500-page book has the answers to the team-level challenges that hold companies back, and includes all the content we teach in our six-figure agile transformation programs.

“This book describes not just every step of the agile process, but the entire process of becoming agile, the production of agile products, and how to deal with the changes that need to happen across an organization’s whole culture.” – Amazon Reviewer

In The Epic Guide to Agile, you’ll discover:

  • Personal examples and anecdotes to tackle problems at their source
  • Effective ways to introduce agile and Scrum into your organization
  • The exact system to achieve productive sprint planning sessions and successful sprints
  • The typical issues that can doom your team and how to conquer them
  • The testing and source code control techniques your team needs to be successful
  • Tricks to smoothly get your product into production and much, much more!

Ascendle CEO Dave Todaro has lived and breathed software development for over three decades. After running successful agile teams on a daily basis, he’s ready to share his insights and techniques to help your company reap the benefits of his experience.

Part I: Understanding Scrum Fundamentals

1 Introduction to High-Performance Teamwork

1.1 Creating Dream Teams

1.2 Why Does Scrum Work?

1.3 Is Scrum Just for Software Development?

1.4 How Agile Differs from a Traditional Waterfall Approach

1.5 Scrum Is for Any Complicated or Complex Project

2 Scrum’s 10 Guideposts

2.1 Three Roles

2.2 Four Ceremonies

2.3 Three Artifacts

2.4 This is Too Simple. How Can It Possibly Work?

3 The Product Backlog

3.1 The Single Shared Source of Truth

3.2 The Product Backlog Belongs to the Product Owner

3.3 Requirements Evolve Over Time

3.4 Discussing the Backlog with the Team is Important

3.5 Tracking the Projected Schedule with a Release Burndown Chart

4 User Stories

4.1 A User Story is a Descriptive Sentence

4.2 Details Are Added Through Conversations

4.3 What, Not How

4.4 Each User Story Has a Size Estimate

4.5 Additional Written Details Are OK

4.6 Some Traditional Specifications Are OK Too

5 The Sprint

5.1 Eliminating the Death March

5.2 The Imminent Deadline and the Power of Positive Stress

5.3 Everything is Done During a Sprint

5.4 Benefits of the Sprint Approach

6 Scrum Ceremonies

6.1 Sprint Planning

6.2 Daily Standup

6.3 Sprint Review

6.4 Retrospective

6.5 Other Optional Ceremonies

6.6 A Typical Ceremony Schedule

6.7 Aren’t All These “Ceremonies” Wasting a Bunch of Time?

7 Scrum Roles

7.1 The Product Owner

7.2 The ScrumMaster

7.3 The Development Team

8 The Sprint Backlog

8.1 Visualizing the Work of the Sprint with a Sprint Task Board

8.2 Keeping Track of Who’s Working on Each Subtask

8.3 Understanding How Much Time is Left for Each Subtask

8.4 Tracking Sprint Progress with a Sprint Burndown Chart

8.5 My Company Requires Creating Status Reports. Are We Allowed to Do That?

9 The Product

9.1 The Product is Built Iteratively and Incrementally

9.2 The Traditional Approach: Building 100% of Nothing

9.3 The Agile Approach: Building 100% of Something

9.4 The Definition of Done

9.5 Shippable vs Something You Would Ship

Part II: Understanding Agile Software Construction

10 Introduction to Agile Software Construction

10.1 What is “Software Construction?”

10.2 Why is Software Construction So Important in an Agile Context?

10.3 Why You Need to Know About This Technical “Stuff”

10.4 Agile Software Construction Concepts

11 Creating a Shippable Increment Requires Team Test Environments

11.1 Traditional Testing Approaches Don’t Work in an Agile Environment

11.2 Test Environments Eliminate “Works on My Machine!”

11.3 What the Scrum Team Needs for Test Environments

11.4 Providing Test Environments May Require Creative Thinking

11.5 The Scrum Team Needs to Control Their Test Environments

11.6 The Ability to Automatically Deploy Code is Critical

11.7 Tools to Manage Team Test Environments

12 Managing Source Code Properly Avoids Pain When “Life Happens”

12.1 Version Control Allows Effective Collaboration

12.2 Branches Isolate Code to Manage the Unexpected

12.3 A Distributed Version Control System Makes Branching Easy

12.4 Reviewing Code Before Merging a Branch Increases Quality

12.5 Git Flow Provides a Strategy for Branch Management

12.6 Keys to Avoid Merge Hell and Code Review Bottlenecks

13 Automated Unit Testing: The Foundation of Code Quality

13.1 The Problem with Relying Solely on Integration Testing

13.2 Automated Unit Testing: Ensuring Code Works All the Time

13.3 Running Tests Automatically Avoids Human Error

13.4 A Side-Benefit: Unit Tests Document Code for Future Programmers

13.5 Isolating Dependencies Makes Testing Easier

13.6 Test-Driven Development (TDD) Creates a Test-First Culture

13.7 Code Coverage Analysis Keeps Everyone Honest

13.8 Adding Unit Tests for Discovered Bugs Prevents Them from Coming Back

13.9 My Team Says We Should Use Integration Tests Instead of Unit Tests

14 Acceptance Testing: Making Sure Everything Works Together

14.1 Scenarios Allow Pre-Visualizing a User Story to Avoid Disappointment

14.2 Given, When, Then: Making Tests Understandable to Everyone

14.3 Write Acceptance Tests Early During a Sprint to Reduce Risk

14.4 Perform Acceptance Testing in Every Environment to Avoid Career-Limiting Moves

14.5 Create an Automated “Smoke Test” With the Most Critical Scenarios

15 Agile Architecture and Technical Design

15.1 Architecture Doesn’t Disappear with Agile: It Becomes “Emergent”

15.2 Avoiding YAGNI by Leveraging the “Last Responsible Moment”

15.3 Attaining Technical Excellence Without Telling the Team How to Do It

15.4 Development Teams Need to Consider the Big Picture

15.5 An Experienced Technical Team Member Can Embed Architecture Intelligence

15.6 Creating a Technical Design for Each User Story Encourages Collaboration

15.7 Coding Standards Are a Critical Success Factor

15.8 Technical Communities of Practice Encourage Both Innovation and Consistency

Part III: Laying the Groundwork

16 Here Be Dragons: Preparing for the Challenges You’ll Face

16.1 How Your Organization Will Change

16.2 How Project Managers and the Project Management Office (PMO) Fit In

16.3 How to Start: Pilot Team or the “Big Bang” Approach?

16.4 Success Factors to Guide Your Agile Adoption

16.5 How Long Will It Take to Adopt Agile?

16.6 A Sample Agile Adoption Timeline

17 Forming Your Pilot Scrum Team

17.1 Select a Team You Think Can be Successful

17.2 Select a Product Built Using Agile-Friendly Technology

17.3 Select Team Members Who Can Be Dedicated to the Pilot Team

17.4 Choosing the Product Owner

17.5 Choosing the ScrumMaster

17.6 Don’t Have One Person Be Both Product Owner and ScrumMaster

17.7 Assembling the Development Team

17.8 Seat Your Co-Located Team Together

17.9 Distributed Teams and Multiple Time Zones

18 Your Team’s Path to Excellence

18.1 Four Stages of Learning: The Conscious Competence Model

18.2 The Cognitive Apprenticeship Learning Method

18.3 Teaching the Fundamentals

18.4 Starting Your Team’s Experiential Learning

18.5 Agile Coaches

18.6 What About Agile Certifications?

19 Creating the Initial Product Backlog

19.1 The Backlog Creation Process

19.2 Create a List of Roles to Understand Your Users Better

19.3 Brainstorm Features for Each User Role

19.4 Convert Roles and Features into User Stories

19.5 Group User Stories into “Must Have,” “Nice to Have,” and “Someday Maybe”

19.6 Prioritize the Backlog by Business Value

19.7 Write Acceptance Criteria

20 Estimating the Size of the Product Backlog

20.1 The Power of Relative Size

20.2 Story Points: An Abstract Measurement of Size

20.3 Rapid Estimation with Planning Poker

20.4 Preparing to Estimate

20.5 Story Points Are NOT About Time

20.6 The Planning Poker Process

20.7 How Long Should Estimating Take?

21 Creating an Initial Schedule Projection

21.1 The Chicken and Egg Problem: What’s the Velocity?

21.2 Options to Predict the Team’s Velocity

21.3 Breaking Down Some Stories into Subtasks to Estimate Velocity

21.4 Using the Cone of Uncertainty to Anticipate the Unknown

22 Splitting User Stories for Increased Momentum

22.1 Avoid “Traveling” Stories by Splitting Them

22.2 The Six-Way Model for Splitting User Stories

22.3 SPIDR: An Alternative Method for Splitting Stories

22.4 Use INVEST to Ensure the Quality of Split Stories

22.5 Who Splits User Stories and When?

23 Final Preparations Before Your First Sprint

23.1 What You Should Have in Place Before Starting Your First Sprint

23.2 Complete Initial User Experience (UX) Design

23.3 Deploy Agile Tools

23.4 Define Scrum and Technical Standards

23.5 Configure Developer Workstations

23.6 Set Up Distributed Version Control

23.7 Create Initial Code Framework: The “Walking Skeleton”

23.8 Configure Continuous Integration

23.9 Provision Team Test Environments

23.10 Establish Continuous Deployment

23.11 Research Production Deployment Considerations

23.12 Should We Use a “Sprint Zero?”

Part IV: Building the Product

24 Determining Sprint Logistics

24.1 Selecting the Best Sprint Length

24.2 Picking the Best Day of the Week to Start a Sprint

24.3 Scheduling the Sprint Planning Ceremony

24.4 Preparing for the Sprint Planning Ceremony

24.5 A Sample Sprint Planning Agenda

25 Planning the Sprint

25.1 Setting the Stage for the Team

25.2 Estimating the Team’s Capacity for the Sprint

25.3 Determining How Much Work Can be Done and the Plan of Attack

25.4 Decomposing a Task or Bug into Subtasks

25.5 How Much of the Team’s Capacity Should be Planned?

25.6 What If There Isn’t Enough Time to Finish the Plan?

25.7 Scheduling Scrum Ceremonies for the Sprint

25.8 Finish Sprint Planning by Transitioning to Immediate Action

26 Orchestrating the Daily Work of the Sprint

26.1 Using the Daily Standup to Stay in Sync

26.2 Tracking Progress Against the Plan with the Sprint Task Board

26.3 Keeping the Sprint Task Board up to Date Every Day

26.4 Using the Sprint Burndown Chart to Stay on Track

26.5 Summary of Best Practices

27 A “Zero Defects” Approach to Dealing with Bugs

27.1 Fix Bugs Before Writing New Code

27.2 How to Create a Zero-Defects Culture

27.3 Effectively Documenting Bugs

27.4 How Nasty Is It? Using Priority and Severity to Classify Bugs

27.5 Handling Bugs Introduced during the Sprint

27.6 Addressing Newly-Discovered Bugs That Existed at the Start of the Sprint

27.7 Dealing with a Customer Issue Caused by a Critical Bug

27.8 Timeboxing the Bug Fixing Effort

27.9 What to Do with Bugs That You Won’t Fix

27.10 Handling Bugs That Can’t Be Reproduced

27.11 What to Do with a Legacy Bug List Inherited by the Team

28 Providing Transparency and Getting Feedback With the Sprint Review

28.1 Who Should You Invite to the Sprint Review?

28.2 Selecting the Best Sprint Review Duration

28.3 Preparing for the Sprint Review

28.4 Reviewing What the Team Worked On

28.5 Demonstrating New Functionality in the Product Increment

28.6 Reviewing the Projected Schedule

28.7 A Sample Sprint Review Agenda

29 Driving Continuous Improvement With the Sprint Retrospective

29.1 Is This Really a Valuable Use of Time?

29.2 The Art of Self-Reflection: Questions to Ask During the Retrospective

29.3 Leave Egos, Titles, and Experience at the Door

29.4 Set the Bar High

29.5 Don’t be Too Nice

29.6 How to Make Change Happen

29.7 Common Problems and Ideas to Address Them

30 Confidently Releasing Your Product into Production

30.1 A Tried-And-True Release Process

30.2 Test Environments Required to “Certify” the Release

30.3 The Five-Step Release Process in Detail

30.4 Triaging Bugs Discovered During the Release Sprint

30.5 Orchestrating the Work of the Release Sprint

30.6 But It’s Not This Easy at My Company

30.7 Life After the Release Sprint

About the Author

Programming since age 11 and shipping his first commercial application at 15, Dave Todaro has lived and breathed software development for the past 35+ years. He’s trained and managed teams responsible for building award-winning, mission-critical software in a variety of leadership roles.

Dave has a particular passion for predictable, repeatable, and consistent software development, and fell in love with Scrum when he adopted it over 11 years ago. He’s since refined the process with his teams and has traveled the world, speaking to thousands of software professionals about a variety of agile topics.

Dave is founder and CEO of Ascendle, a Boston-based firm that leverages Microsoft technologies to build web and mobile apps for the world’s leading companies.

Learn more about Dave on LinkedIn.

Sign Up For Bonus Content

Enter your information below to get free bonus content!

* indicates required