Basecamp Flashcards
6-week sprint time
6-week is long enough to build something meaningful e from start to delivery, short enough to have the deadline insight.
Shaping the work
== User story definition by architect
This is the key part. Break down the architectural components for “Cycle Teams”
Architectural decision/direction making
High-level with enough details
Cycle Team
==Spotify Squad
Autonomous (decision making), vertical, cross-function, all aspect required to complete a feature is within the team.
Autonomous = Accountable (ownership)
Iterate on end-to-end pipeline
== Iterate on MVP
do not iterate on a single component and work on that component only
Iterate on a end-to-end feature from simple to complicate/end product:
- finish a simplest end-to-end
- add an extra feature the simplest end-to-end
- repeat 2
- delivery the end-to-end with all features
Shaping Up
== Resolving and Scoping == User story definition
== Provides solution WHAT, not HOW
== It is bounded (clear in-scope and out-scope divide)
== You don’t need C/C++/JAVA to shape up, though you need those languages to implement
Scoping: what is in-scope and what is out-of scope
Resolving = Architecting, External Dependencies Identification, Risk Estimating
Final Defintion:
- Problem/User Requirement
- Acceptance Criteria
- Architectural Solution
- Dependencies, Risks, Limitations
User Requirement (words) alone are too abstract Wireframes (steps to implement) are too concrete
Shaping Up
== Resolving and Scoping == User story definition
== Provides solution WHAT, not HOW
== It is bounded (clear in-scope and out-scope divide)
== You don’t need C/C++/JAVA to shape up, though you need those languages to implement
Scoping: what is in-scope and what is out-of scope
Resolving = Architecting, External Dependencies Identification, Risk Estimating
Final Defintion:
- Problem/User Requirement
- Acceptance Criteria
- Architectural Solution
- Dependencies, Risks, Limitations, Assumptions
- Clarify what is NOT supported (if there is confusion or state future following up user stories)
User Requirement (words) alone are too abstract Wireframes (steps to implement) are too concrete
Setting the appetite
== Always starts on a MVP, then iterate
If user ask for a big feature (customer has big appetite)
give them a MVP first (give them a small bite first)
If they want more, iterate on the next bite.
Appetite
== T-shirt size/Scope of the user story that can be don
Small-batch (3-person squad 1 week)
(Midium-batch)
Big patch (3-person squad 6 weeks)
Appetite
== T-shirt size/Scope of the user story that can be don
Anybody can suggest expensive and complicated solutions. It takes work and design insight to get to a simple idea that fits in a small time box
Small-batch (3-person squad 1 week)
(Midium-batch)
Big patch (3-person squad 6 weeks)
***Difference appetite vs estimate
Estimate: This is the design, how long do you need to finish? (Fit time into scope)
** Appetite”: You have 6 weeks, what can you deliver? (Fit scope into time)
“good “is good enough (know your constraints)
I.e. Don’t Let the Perfect Be the Enemy of the Good
External factors must be considered.
A solution with 64M RAM is different from one that is 256 RAM
Don’t have a big appetite
Remember, the 6-week is fixed and given. You need to come up with an appetite (how much can be done in 6 weeks)
Learn how to say No
Don’t commit undefined user stories…leave a open topic, form an exploring committee, do a MVP in lab week
Avoid Grab-bags (big appetite without clear definition of scope)
== Redesigns == Refactoring
== Replay Technical Debt
A tell-tale sign of a grab-bag is the “2.0” label
Instead we should back “refactoring” into each iteration.
Elements (to consider) for a software solution to an appetite (scoped user story) after fat-marker or breadboard discussion
== Acceptance Criteria
- right people (architects, stake holders)
- right level of details (no wireframes remember), use big black boxes, breadboarding, fat-marker sketches
This is like Acceptance Criteria
