cs-c2130 / cs-c2140 / cs-e4910 software project 1 / 2 / 3 · – basics of the scrum process •...
TRANSCRIPT
CS-C2130 / CS-C2140 / CS-E4910
Software Project 1 / 2 / 3
Lecture 2: Scrum Basics
20.9.2017
Agenda
• Scrum Basics / Prof. Casper Lassenius
• Applying Scrum on this course / Jari
Vanhanen
21.9.2016
Scrum Basics
Prof. Casper Lassenius
Aalto University
21.9.2016
Goals of This Lecture
• Teach you
– Why you need a process for working in your projects
– Basics of the Scrum process
• Roles
• Process steps
• Terminology
• After this lecture
– You are able to participate in the Scrum game
– You know the basics of Scrum
• This lecture is based on
– Scrum Primer
– (Scrum Guide)
21.9.2016
Why Process?
• In an organization?
• In a corporate project?
• In your project?
21.9.2016
Why Scrum?
21.9.2016
Scrum Process:
21.9.2016
Scrum Roles
21.9.2016
Scrum Team
Scrum team = Team + Scrum Master + Product Owner
21.9.2016
Product Owner
• Responsible for maximizing
return on investment, thus has
the final authority
• Identifies product features
• Prioritizes the features
• Interacts regularly with the
team, e.g. reviews the Sprint
results
• Product Owner ≈ Product
Manager ≈ Customer
21.9.2016
The Team
• Develops the product and provides ideas to the Product Owner about how to make the product great
• 7 ± 2 people
• Is cross-functional (includes all expertise necessary to deliver a potentially shippable product each sprint)
• Is self-managing: high degree of autonomy and accountability
• Every team member is just a team member, no other roles
21.9.2016
Scrum Master
• Helps the product group learn and apply
Scrum to achieve business value
• Is part of the Scrum Team
• Is NOT the manager of the team
members, NOR a project manager OR
team lead
• Serves the team, e.g. helps to remove
impediments, protects from outside
interference
• Is a coach and teacher, especially Scrum
principles and practices
• Who is the project manager in Scrum??
21.9.2016
Scrum Process
21.9.2016
Sprint / Iteration
• Time-boxed development cycles
• No more than 4 weeks, 2 weeks most common
• Never extended: ends exactly when planned, contents give flexibility
• The output of every sprint is: “Potentially Shippable Product Increment”, which means that item chosen for that sprint are “Done” (according to the DoD = Definition of Done)– System is integrated
– Fully tested
– End-user documented
– Potentially shippable
21.9.2016
Sprints (CS-C2130)
• At least six Sprints
– 225h / 6 = 37.5h
• In the beginning of the project, plan for each sprint
– start and end dates
– effort allocation per person
• Guidelines for the content of Sprint 0 and Last Sprint
13.9.2017
See Project Manual
Sprint 0 (CS-C2130)
• Sprint goal
– “Set up the project so that everything is ready for starting sw development work
from the first day of the following Sprint.”
• Main tasks
– product vision and initial Product Backlog
– prototyping, selecting and studying technologies
– selecting work methods and tools (e.g. how Scrum events will be done)
• Results presented also to the Coach
13.9.2017
Last Sprint (CS-C2130)
• Focuses on finalizing the product for the final delivery to the PO
• Some tasks
– acceptance testing by the Client
– bug fixing and finalization (no more new features)
– preparing an excellent software demo for the project review
13.9.2017
Product Vision / Release Planning
• No instructions given by Scrum
• Needed especially in case of a new
product
• The Product Owner and Team shape
a Scrum Product Backlog, including
– Planning the contents of the release
– Estimating, refining estimates
– Prioritizing
• May take a few days or a week…
• Not needed in continuous product
development, done by product
backlog refinements in every sprint
21.9.2016
Product Vision (CS-C2130)
1. Why?
– explain why the product is being built (the business view)
2. What?
– list the main goals for the product
– include critical quality attributes that are difficult to include in the
Definition of Done
3. For Whom?
– characterize the end users
21.9.2016
Product Backlog
• Is a prioritized list of customer-centric features
• “Everything that could be done by the Team ever in order of priority”
• Includes “items”, e.g. new customer features, major engineering improvement goals, research work, (known defects)
• Includes effort estimates
• Is detailed appropriately
• Is regularly refined (“grooming”) = splitting, estimating, re-estimating items
21.9.2016
Backlog Item
• Often two types
– Epic
– User story
• Should be in a (real) backlog management tool
– Jira, Trello, Agilefant, VersionOne, …
• Product backlog
– Size estimates in story points
• Sprint backlog
– Effort estimates as hours (or story points)
– Rules for updating effort left
21.9.2016
User Stories and Epics [1]
• User story
– Basic format: “As a [type of user] I [want/can/am able to/need to/etc.] so that [some reason].”
– Can be in other formats, as long as the above aspects are covered
– Works well for functional requirements, less well for quality attributes
– Can be implemented in one Sprint
• Epic
– Basically a “big user story”, i.e. cannot be implemented in a single sprint
– Usually broad in scope, short on details, and will commonly need to be split into multiple, smaller stories before the team can work on them
21.9.2016
[1] https://www.scrumalliance.org/community/spotlight/mike-cohn/march-2014/agile-user-stories-epics-and-themes
Scrum Board
21.9.2016
Sprint Planning I
• Participants: Product Owner,
Team, Scrum Master
• Goal: understanding WHAT
the Product Owner wants and
WHY they are needed
• Discussion of the goals
context of the highest priority
items
– PO explains
– Team asks questions
21.9.2016
Sprint Planning II
• Participants: Team, Scrum Master (Product Owner reachable for questions)
• Focus on HOW to implement the items the Team decides to take on– Team decides how much work it will
complete!
• May contain:– Estimating the team’s capacity for the next
sprint
– Overall design
– Selecting and splitting product backlog items into tasks – building sprint backlog!
– Estimating items/tasks
– Selecting as many items team estimates they can realistically complete: sprint “commitment” / forecast
21.9.2016
Daily Scrum Meeting
• Participants: Team, Scrum Master (Product Owner optional)
• Update and coordination between team members – not a status reporting to anybody else
• Max 15 min
• Each member report to the other team members:– What has been accomplished since the
last meeting?
– What will be done before the next meeting?
– What obstacles are in the way?
• If discussion needed: follow-up meetings agreed and held afterwards
21.9.2016
CS-C2130
• Once / week
• F2F preferable
• Synchronous online
possible
Definition of Done
• Defined what is needed for something
(e.g. task, backlog item, sprint) to be
considered “DONE”
• Sometimes people say it is ”done-done”
to mean it meets the criteria for DoD
• You must define your own DoD (and
follow it!)
• Often at several levels
– Task, User story, Sprint
• Typically things like
– Code is implemented, commented, integrated,
reviewed/tested
21.9.2016
CS-C2130, minimum DoD:
• unit testing
• functional system testing
• coding standard
Sprint Review
• Participants: Team, Product Owner,
Scrum Master, other stakeholders
invited by the Product Owner
• Inspection and adaption related to the
product increment of functionality
– What is going on with the product and team
– What is going on with the Product Owner
and the market
– In-depth conversation
– Includes hands-on inspection of the real
software running live
21.9.2016
Sprint Retrospective
• Inspection and adaption related to the process and environment
• Participants: Team, Scrum Master, Product Owner (optional)
– Team discusses what’s working and what’s not working and agree on changes to try
– Usually the Scrum Master facilitates
– Different techniques, try different ones!
21.9.2016
Being Efficient: Doing a Sprint Change
• In one sitting
– Sprint review
– Retrospective
– Sprint planning
• Ca 0,5 days
• Requires access to Product Owner
– Sprint review
– Sprint Planning I & III
21.9.2016
Tracking Progress
Burndown / burn-up charts
21.9.2016
Want to Know More?
– Scrum Guide
– Scrum Primer
21.9.2016
QA & Testing
• Define and deliver minimum content agreed with
Product Owner
• Define and test quality attributes (non-functional
requirements)
• Peer testing (as defined by the course)
21.9.2016
What if Scrum Does Not Work for Us?
• Try it (for real) first
• If you really need to change it
– Make a motivated proposal
– Try the changed version
21.9.2016
End of Scrum Basics
21.9.2016
Additional requirements for the course
projects
• Project Reviews
• Process Overview Document
• Technical Overview Document
• Time Tracking
• Learning diary
13.9.2017
See Project Manual
Project Review (CS-C2130)
• December, February and April
• Participants– student team, coach, teacher, PO, and possibly other people (Accenture, guests)
• Team presents data on the project status and the results (software demo)– status of Sprint Goals and selected Product Backlog items
– main findings from Sprint retros
– software quality
– effort usage per person
• After each project review, PO and coach evaluate the project
13.9.2017
See the Progress report template
Document – Process Overview
(CS-C2130)• Document briefly the currently used work practices and tools so that
all stakeholders can understand how the team works
• Minimum content
– project schedule and effort
• Sprints
• other main events (Project Reviews, team work sessions)
– recurring events of the Sprints (how and when)
• Sprint Planning, Daily Scrums, team work sessions, Sprint Review, Sprint Retros
– other main practices and tools
• project work (backlogs, time tracking, communication etc.)
• development (version control, testing etc.)
13.9.2017
See the template
Document – Technical Overview
(CS-C2130)• General goals
– Helping the Scrum Team during the project, e.g., in communicating about the
design or in dividing responsibilities
– Meeting the Client's needs after the project
• Very project specific
• Minimum content
– Document briefly the most important architectural design decisions
– Document one or more relevant views of your architecture design
• see e.g. 4+1 architectural view model
13.9.2017
Time Tracking (CS-C2130)
• Total effort spent per student per each Sprint
– must be available to the Scrum team and Coach
– must be updated at least weekly
• impossible to remember what you did last week
• Some backlog management tools support time tracking
• Spreadsheet can work too
– if you are not interested in task level tracking
13.9.2017
See Google Sheet
example
Learning diary (CS-C2130)
• Write a new entry to your diary just before each Project Review
1) three educational observations related to the use of Scrum or other work
methods
2) a summary of your main contributions to the project since the previous entry
• Furthermore, write an entry about the Scrum Game immediately
after your participation
13.9.2017
Submitted individually
to MyCourses.
Summary of the required artifacts
(CS-C2130)• Product vision (see Template)
• Product backlog
• Sprint Goals of the current and completed Sprints
• Sprint Backlog of the current Sprint
• Definition of Done
• Test session charter(s) for peer testing (see Template)
• Allocated and spent effort per person per Sprint
• Process overview (see Template)
• Technical overview
• Progress report / Final report slides (see Template)
• Learning Diaries
13.9.2017
Send a link to the materials to the teacher, coach and PO
– 24 hours before each project review
Next Steps
• CSM Training
• Scrum Game
– Scrum Masters will get a “game manual” by e-mail two days before their session
• Don’t give it to the team members!
– Session 3 (Fr 13.10.) cancelled
– Session 1 (Mo 2.10.) registrations immediately
• sandwiches etc. will be ordered tomorrow morning!
• Lecture on We 4.10. 16:15-18 in T4
– for Scrum Masters only
• Sending Team CVs to Clients 11.10. ->
21.9.2016