marion de groot - scrum and specs
DESCRIPTION
"As a requirements analyst I often hear 'Oh we don't do specifications, we do Scrum!' Although fewer specs are needed in a true Scrum environment with an experienced team, this doesn't mean specs can be eliminated altogether. A new balance needs to be found. This presentation elaborates on this discussion and gives you hands-on tips for working with specifications in a Scrum environment. Subjects covered: - What can we consider as specifications - Why is it important to specify in a Scrum environment? - How much should be specified? - When in the process do we make and use specs? - How to specify?"TRANSCRIPT
“We don’t do Requirements, we do Scrum”
The importance of thinking before doing
Scrum and SpecsThe Strain of
Content
Who am I?
What are we talking about?
Why specs?
How much specs?
When to specify?
How to specify?
Marion de GrootPick my brain – Your idea into ITRequirements analystFunctional designerScrum Product Owner
Who?
My resume
Industrial Design Engineering, TU DelftGraduation project: A support tool for the Chinese village doctor
Application Designer @ KSYOS TeleMedical Center
Functional Designer @ Up2 Technology
Requirements Analyst @ Pick my Brain
Who?2000
2006
2010
2012
2014
My mission
“Happier customers and developers
through clear, complete and concise
requirements”
Who?
Are we talking about?What
Waterfall
Define
Design
Develop
Test
Deploy
What?
The Agile Manifesto
We value
Individuals and Interactions
Working software
Customer collaboration
Responding to change
Over
Process and tools
Comprehensive
documentation
Contract negotiation
Following a plan
What?
Agile development
What?
Define
Design
DevelopTest
Deploy
Iteration
Daily Scrum
Sprint1-4 weeks
Scrum
ProductBacklog
SprintBacklog
Working incremental piece of software
What?
Specifications
Describe the product Are recorded
Examples Documents Post-its Photos Drawings
What?
Waterfall extremist: “Document everything!”
Agile extremist: “All documents are waste!”
“Specifications should serve a purpose.”
Documentation scale
What?
Do we make requirements?Why
Customers
Why?
Developers
Why?
Start of project
Expectation management Cost estimate Risk management Prioritising
Why?
During project
Clear work instructions Avoid rework
Why?
End of project
Guidelines for testing Avoid disagreement Reference Quality Assurance
Why?
Requirements are for
People Communication
Why?
Who makes them?
Specifications should be made by someone who understands: Customer Product Technology
For example Product Owner Other team member
Why?
Involve stakeholders and team members Use their expertise Sense of ownership Be on one line Approve
Why?
Keep it simple
Images, tables, diagrams Drawings and sketches Avoid jargon Be concise
Why?
Should be specified?How much
Depends on
Product Team Customer
How much?
Product
How much?
Complex New
Unknown for team
Technology
Team
How much?
Distributed
Different culture / background
NewTime difference
Customer
How much?
Stubborn
Unfamiliar with IT
New
When can we plan a story?
What’s your definition of ready?
How much?
Should we specify?When
Solid basis
Sprint 0 Research, Analysis General requirements and structure Context, Goal, Vision Priorities Epics
When?
Bit by bit
During the project Define use cases, user stories Elaborate when needed
Use online collaboration tools
When?
Staggered sprints
When?
ARequirements
Development
Sprint 0 Sprint 1 Sprint 2
B C
A B C
Sprint 3
Can we specify?How
User Stories
As a CustomerI want to be able to approve the offerSo that I can get my product
How
Conclusion
Good requirements Save time, money and frustration Aren’t endless documents Are Agile
Questions?
