1. Focus: Scrum Organization of a Scrum development work
See Ken Schwaber at Google, September 2006
One hour video recording of one of the originators of Scrum

2. Scrum characteristics
Transparancy – exposesproblems early
Strict prioritization
Empirical & adaptive
Short feedback loop
Continuous improvement
Frequent & regular delivery of working software
Plans are needed, but they are always wrong
Yesterday’s weather
Cross-functional self-organizing team
Pull scheduling – team chooses how much work to commit to
Timeboxing
Face-to-face communication
Simple tools

3. Scrum process

4. History

5. Slack

6. Life wisdom 3 things we wish were true
The customer knows what he/she wants
The developers know how to build it
Nothing will change along the way
3 things we have to live with
The customer discovers what he/she wants
The developers discover how to build it
Many things change along the way

7. Monolithic vs Incremental

8. Push vs Pull

9. Agile vs Waterfall

10. Does it work?

11. Relation between Scrum and XP

12. Feedback cycles

13. A Scrum sprint
Some details

14. MoSCoW / Pareto, solve top 20% requirements first
A Scrum Sprint
Disciplines
Initial requirements
Pre-project
Sprints
Requirements
Analysis
Design
Implementation
Test
MoSCoW / Pareto, solve top 20% requirements first
Pareto principle:
Focus on the 20% of overall requirements giving 80% of the business benefit
Then only focus on the main success scenario of those requirements
A supporting principle in DSDM (similar to Scrum): No system is built perfectly in the first try (the pareto principle-80/20 rule). In the process of developing an information system, 80% of the business benefit comes from 20% of the system requirements, therefore DSDM starts implementing this first 20% of system requirements to meet 80% of the business needs, which is good enough as long as the users are intimately involved in the development process and in a position to ensure that the missing 20% would not cause any serious business consequences. Implementing the entire requirements often causes the project to go over deadlines and budgets, therefore it is most times unnecessary to construct the perfect solution.
MoSCoW (from DSDM):
MUST have this requirement to meet the business needs (also acronym for Minimum Usable SubseT)
SHOULD have this requirement if at all possible, but the project success does not rely on this.
COULD have this requirement if it does not affect the fitness of business needs of the project.
WOULD have this requirement at later date if there is some time left (or in the future development of the system).
Sprints #1 # # #4
[Pareto], [MoSCoW] 14

15. Iterative Development – One Iteration
Each iteration is a mini project involving all disciplines
Normally not in sequence
* [until finished]
capture in
Requirements
Requirements Model
verify requirements in
Analysis Model
Analysis
: Actor
: Class
specify requirements in
Test Model
Test
Architecture Model
Architecture and Design
realise requirements in
Design Model
implement requirements in
Code
Implementation 15

16. The Sprint Flow Sprint planning meeting, eight hours Time box
Team and Product Owner update and prioritize Product Backlog 4h
The team plans for and starts the sprint 4h
Place tasks in the Sprint Backlog, the sprint has started
Team runs sprint d
Team holds Daily Scrum ’
Synchronizes team members
What is done, what is planned, what impediments stop me
Team updates Sprint Backlog
Team holds Sprint review meeting 4h
Demonstrate sprint results to anyone interested
Scrum Master holds Sprint retrospective meeting with Team 3h
Team revises and improves development process 16

17. The Scrum Process Overview
Planning meeting
Vision: Anticipated ROI, Releases, Milestones. Initial requirements
[Scrum 07] 17

18. What does Done mean? Deliverable to the customer
Ready to be used in a product
QA, documentation, refactored, meets good engineering practice standards
What if I am unable to finish all this during this sprint?
Some options
Increase effort, work harder, longer, smarter
Cut quality, skip design, testing, intergation, documentation
Cut features
What are the consequences of each?
Which one is least / most desireable

19. Consequences of Rushing or Cutting Quality
Rushing: Working overtime, cutting breaks, adding people
Leads to burn out
Error rate increases
More crap produced in shorter time
Cutting quality
Harder to reuse and develop further
Increased technical dept due to lack of refactoring
Reduces velocity
Makes it harder to meet new goals
Increases need to rush or cut quality in subsequent sprints
Only sustainable option
Cut features, postpone to lates sprints and/or releases
Informed decisions with the PO involved
[Kniberg 08]

20. Sprint Planning Meeting
Product Owner selects top priority features from Product Backlog
Candidates for next sprint
Feature = something useful for product owner
Closer to top  more detailed stories, more scenarios
Team estimates features from top until sprint velocity reached
Story Points, Sprint velocity = number of story points done in earlier sprints
Only complete features count
Feature estimates kept constant throughout product development
Planning Poker
Only rough, relative estimates (story points) for whole features
Product Owner writes acceptance tests
For selected features
Supported by team members
[Backlog item practice], [Planning Poker]

21. Sprint Starts Team builds initial Sprint Backlog
Breaks down features to tasks
Add database tables or fields
Write data access routines
Increase domain model functionality
Add user interface
Etc etc
Makes initial task estimates by hours
Do not map directly to Product Backlog scale
Build sprint backlog
Workshop tools
Off you go
The sprint has already started, time is ticking

22. Work During Sprint, for One Task at a Time
Select an acceptance test corresponding to the user story
Prepared by PO
Set test property on local workstation only
Analysis and design
For the short term items
No AP (Analysis Paralysis)
No DBUF (Big Design Up Front)
Normally standing in groups in front of a whiteboard
Incrementally and iteratively develop features in tiny steps
Document example in NUnit, implement, refactor
Apply all design skills and software engineering practices during refactoring
Until Done with that task and eventually that user story

23. Daily Stand Up Meeting Purpose
Team member inform each other of their progress and need for assistance
Three items:
Achieved yesterday, goal for today, impediments
Common pitfalls – discuss what kind of problems they cause
Team members report to the project manager
Team members embellish their progress
Team members report ”done” before Done
Team members do not offer to help each other
Time boxed to 15 minutes
Expanded discussions are postponed to additional meetings

24. Scrum Demonstration With Product Owner and any interested party
You have to deliver a piece of business functionality every sprint
Last day of every sprint
End of sprint time box
Time and date fixed in advance at regular pace
Unconditional
Demonstrates that what was promised actually works
No excuse
Problems should have been raised and solved earlier
Include ”How to demonstrate” in Product Backlog
Next up
Team and Scrum Master: Retrospective meeting
Product Owner: Plan priorities for next sprint

25. Scrum Retrospective Meeting
Team and Scrum Master
The single most important activity for continuous improvement
Återblicken, blog Tobias Fors, Citerus (in Swedish)
Assess what has worked and what has not during last sprint
Make list of what needs to improve
Suggest changes
Select at most one item to change during the coming sprint
Discuss how to implement the change
Next up
Team, Scrum Master, Product Owner: Planning meeting for the next sprint

26. Practices Pair programming TODO: en bild om parprogrammering
Stand up meetings
TDD
Incremental design
Continuous integration
Collective code ownership
Informativ workspace
Coding standard
Sustainable pace

27. Tools Visual Studio Coding and connecting NUnit TDD FitNesse
Integration testing
SubVersion
Version control
Cruise Control
Automation
MSBuild
Putting it all together

28. Group business There will be three groups 5-6 people
We want your groups to work as well as possible together
Good composition
Good teamwork
Good guidance
Different skills
user thinking/requirements
analys/design
coding
testing
Which of the above four is your strongest, according to yourself?
All skills will be needed
Has no bearing to course grade
Also think about if you want to speak English in your group or not

29. More group business
Group yourself in the four corners of the room according to your strong point
English or not