View
105
Download
0
Category
Tags:
Preview:
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.
Citation preview
The Strain of Scrum & Specs
@Marion de Groot marion@pickmybrain.eu
www.pickmybrain.eu
“We don’t do Requirements, we do Scrum”
The importance of thinking before doing
Scrum and Specs The Strain between
Content
Who am I?
What are we talking about?
Why specs?
How much specs?
When to specificy?
How to specificy?
Marion de Groot Pick my brain – Your idea into IT Requirements analyst Functional designer Scrum Product Owner
Who?
My resume
2013 2012 2010 2006 2000
Industrial Design Engineering, TU Delft Graduation project: A support tool for the Chinese village doctor
Application Designer @ KSYOS TeleMedical Center
Functional Designer @ Up2 Technology
Requirements Analyst @ Pick my Brain
Who?
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
Develop Test
Deploy
Iteration
Daily Scrum
Sprint 1-4 weeks
Scrum
Product Backlog
Sprint Backlog
Working incremental piece of software
What?
Specifications
Describe the product Are recorded
Examples Documents Post-its Photo’s 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
New Time 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
When?
Bit by bit
During the project Define use cases, user stories Elaborate when needed
Use online collaboration tools
When?
Staggered sprints
When?
A Requirements
Development
Sprint 0 Sprint 1 Sprint 2
B C
A B C
Sprint 3
Can we specify? How
Conclusion
Good requirements Save time, money and frustration Aren’t endless documents Are Agile
Content
Who am I?
What are we talking about?
Why specs?
How much specs?
When to specificy?
How to specificy?
Questions?
@Marion de Groot marion@pickmybrain.eu
www.pickmybrain.eu
Thank you!
Recommended