6 Scrum Master Skills m6 Slides PDF

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,  Graph percentage holdings by
“select * from table” format currency
- Minimum Viable Product  Graph percentage holdings by
 Sort by country region
 Sort by estimated value  Graph percentage holdings by
property type
 Sort by purchase price
 Click to view property detail page
 Sort by currency
 Convert non-USD values to USD
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  Benefits
 We’ll help you to prioritize the Product
Backlog - Risk is shared between the
 We’ll create and share our Definition of Customer & Vendor
Done - Customer gets highest priority
 We’ll provide forecasts for how long we items first
think it’ll take to complete the Product
Backlog - Customer gets working software
 We’ll deliver done, working software that quickly
meets DoD each Sprint - Customer can change their minds
 You can kill the project with X sprint(s)
notice - 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  Benefits
 We’ll help you to prioritize the Product
Backlog - Risk is shared between the
 We’ll create and share our Definition of Customer & Vendor
Done - Customer gets highest priority
 We’ll provide forecasts for how long we items first
think it’ll take to complete the Product
Backlog - Customer gets working software
 We’ll deliver done, working software that quickly
meets DoD each Sprint - Customer can change their minds
 You can kill the project with X sprint(s)
notice - 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

6 Scrum Master Skills m6 Slides PDF

Uploaded by

Copyright:

Available Formats

6 Scrum Master Skills m6 Slides PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

6 Scrum Master Skills m6 Slides PDF

Uploaded by

Copyright:

Available Formats

Common Questions & Objections

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

 The Sprint boundary keeps you honest

 No good way to quickly know what they owned

 Estimated 4 months of work

 The Product Backlog gets re-prioritized

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

 Testing should not be an after-thought.

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

* - Your testers will not be idle.

 Is something is partially ready, test it

 Write test cases early

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

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

 Code that (theoretically) helps you build systems

 Code that's got no purpose on its own

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

 Emergent Architecture: deliver a PBI that needs security code

 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

 Work on top priority items first

 Deliver done, working software each Sprint

 Provide option to cancel project at end of a Sprint

 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?”

 Work on top priority items first

 Deliver done, working software each Sprint

 Provide option to cancel project at end of a Sprint

 Work to Definition of Done (DoD)

 Cancel the project if it isn’t working

 Don’t build what you don’t need

You might also like