Common Questions & Objections

Benjamin Day
@benday | www.benday.com
“Greatest Hits”
 The Greatest Hits
 “We can’t use Scrum because our PBIs  “How do we develop framework code
don’t fit in a Sprint.” and architecture?”

 “Does undone work just fall into the  “How do you do Scrum on a
next Sprint?” consulting project?”

 “We can’t do Scrum because of QA.”  “How do you do annual budgeting

with Scrum?”
Any PBI that you’re going to do has to be do-able to
Definition of Done within a single Sprint.
“Is it ok for the QA testing to
happen in the next Sprint?”
No. Everything in a single Sprint.
 Why PBIs to Done in a Single Sprint?
 When something is DoD “done”, there’s no more work that has to happen on it
- It’s 100% done
- There’s no “little cleanup” on it

 The Sprint boundary keeps you honest

- There’s no tricking yourself into “it’s done enough for now” or “mostly done”

 You want to be able to change your priorities at the end of the Sprint
- Done means you don’t have to worry about cleaning stuff up or “making the app whole”

 Done in a single Sprint means the team can focus on just work for their current Sprint
No. Everything in a single Sprint.
“We can’t use Scrum because our
work doesn’t fit in a Sprint.”
Features and PBIs don’t have to be the same thing.
A feature that a user thinks of as a ‘feature’
might be a dozen or more PBIs.
“We can’t do Scrum because we can’t get our
features done in a single Sprint.”
Releases still exist in Scrum.
 Release = a group of PBIs
that are deployed at one time
 Features  PBIs in a Sprint
1. Think hard about what your Minimum Viable Product (MVP) is
- “The minimum viable product is that version of a new product which allows a team
to collect the maximum amount of validated learning about customers with the
least effort.”
- Eric Ries
http://www.startuplessonslearned.com/2009/08/minimum-viable-product-guide.html

2. Get creative about how you carve your Feature into small PBIs
 The Real Estate Holdings Report Problem
 Company owned / invested in properties around the world

 Ownership data and property info scattered across multiple databases and Excel
spreadsheets

 No good way to quickly know what they owned

 Create a report

 Estimated 4 months of work

“Scrum says our Sprints are 30 days at maximum.”
 “It’s too complex.
There’s no way we can carve that report up.”
“We can’t do Scrum. The End.”
 Report Converted into PBIs
 Display all holdings in raw,
“select * from table” format
- Minimum Viable Product
 Sort by country
 Sort by estimated value
 Sort by purchase price
 Sort by currency
 Convert non-USD values to USD
 Graph percentage holdings by
currency
 Graph percentage holdings by
region
 Graph percentage holdings by
property type
 Click to view property detail page
 Bottom line:
It’s all about how creative you are
when carving features into PBIs.
You were planning to do
5 PBIs in the Sprint.
You got 3 PBIs done.
What happens to the
remaining two PBIs?
“Do those PBIs just roll to the next Sprint?”
It depends.
 Assuming 30 day Sprints.
At the end of 30 days, is that PBI still a top priority?
Priorities change between Sprints.
 Handling Undone Work from a Sprint
 Undone PBIs go to the Product Backlog

 The Product Backlog gets re-prioritized

 In Sprint Planning, that undone work gets chosen just like any other PBI

 Remember: The Product Owner can change his/her direction at the end of
every Sprint.
"We can't do Scrum because what would QA do at the
start of every Sprint?"
“There's nothing to test until the end of the Sprint."
"I can't have my team of QA people just sitting
around for 50% to 75% of every Sprint."
"Can't we just do the QA work for the Sprint
after the coding?"
No.
A PBI must be do-able to Done in a single Sprint.
 Is Testing Part of Done?
 Does your DoD have anything about PBIs being tested?

 “Testing in the next Sprint” implies that testing is something

that happens after.

 Testing should not be an after-thought.

 Plan for quality or you won’t get it.

 Testing is something that happens
throughout the Sprint. *

* - Your testers will not be idle.

 Testing During the Sprint
 Test continually

 Is something is partially ready, test it

 Write test cases early

 Written test cases enable “developers” to test their own code

- Focuses on quality early
 QA + Scrum

http://www.pluralsight.com/courses/real-world-scrum-team-foundation-server-2013

Go to “Scrum & QA Testing” module. Watch the first chapter.

“QA Testing is Different With Scrum”
“How do you develop framework code?”
 Framework Code
 Code that helps you build other code

 Code that (theoretically) helps you build systems

 Code that (theoretically) provides useful services to other bits of the code

 Code that's got no purpose on its own

 Code that's impossible to "demo" at the Sprint Review

 Answer: You Don’t
 Never develop anything that isn't part of directly delivering a PBI

 YAGNI
- You ain’t gunna need it

 Emergent Architecture
- Software architecture is better when it emerges from what you know you need
 “We need security in our app.”
 Old way: build a security framework
- Does not deliver business value
- Architecture might not be exactly what you need once you start building PBIs

 Emergent Architecture: deliver a PBI that needs security code

- Always deliver business value with your PBIs
- Architecture is exactly what you needed to build the PBI(s)
 Build only what you know you need.
Build only stuff that delivers business value.
 Scrum + Consulting:
Scrum while being paid to write software
for other people or companies.
Consulting projects are often fixed-price.
“We’ll pay you $x.xx to develop these features.”
 Consulting Project Price Types
Fixed Price (FP) Time & Expenses (T&E)
 Feature list is known  Feature list is known

 Known cost to the customer  Unknown cost for customer

 Vendor bills by the project  Vendor bills for each hour

 Low risk for customer  High risk for customer

 High risk for vendor  Low risk for vendor

How does Scrum help?
 FP and T&E assumes fixed feature list
where all features are the same priority.
 Scrum-based Consulting Projects
 Feature list is variable  Product Backlog

 Work in Sprints

 Work on top priority items first

 Deliver done, working software each Sprint

 Provide option to cancel project at end of a Sprint

 Vendor’s Agreement with Customer
 We’ll help you create the Product Backlog
 We’ll help you to prioritize the Product
Backlog
 We’ll create and share our Definition of
Done
 We’ll provide forecasts for how long we
think it’ll take to complete the Product
Backlog
 We’ll deliver done, working software that
meets DoD each Sprint
 You can kill the project with X sprint(s)
notice
 Benefits
- Risk is shared between the
Customer & Vendor
- Customer gets highest priority
items first
- Customer gets working software
quickly
- Customer can change their minds
- Customer can quit the project
“How do we do annual budgeting?”
 “How do we do annual budgeting?”
 Figure out how much it costs to deliver all dreamed up features

 Guarantee what date those features will be delivered

 Implication: Scrum should do this with 100% accuracy

 “How do you do this without Scrum? How accurate are you?”

- Answer: “We just take guesses and the accuracy is poor.”
 This is asking for magic.
Scrum doesn’t do ‘magic’.
 Scrum will help bring sanity.
Scrum will help you manage your risk.
The answer is based on suggestions
from previous chapter.
The difference is that teams are employees
and those employees are a sunk cost.
Budgeting now becomes buying teams
for sprints rather than buying products.
 Scrum-based Internal Projects
 Feature list is variable  Product Backlog

 Work in Sprints

 Work on top priority items first

 Deliver done, working software each Sprint

 Provide option to cancel project at end of a Sprint

 IT’s Agreement with the Company
 We’ll help you create the Product Backlog
 We’ll help you to prioritize the Product
Backlog
 We’ll create and share our Definition of
Done
 We’ll provide forecasts for how long we
think it’ll take to complete the Product
Backlog
 We’ll deliver done, working software that
meets DoD each Sprint
 You can kill the project with X sprint(s)
notice
 Benefits
- Risk is shared between the
Customer & Vendor
- Customer gets highest priority
items first
- Customer gets working software
quickly
- Customer can change their minds
- Customer can quit the project
 Scrum Annual Budgeting
 Work to the Product Backlog

 Work to Definition of Done (DoD)

 Cancel the project if it isn’t working

 Focus is on the cost of the team per sprint rather than cost of a pile of features

 Don’t build what you don’t need

 Next up:
Agile Transformations