SCRUM I dag Hvad og hvordan Hvad er

SCRUM I dag • Hvad og hvordan? • • • Hvad er SCRUM? Hvad er User Stories? Hvordan skriver man en (god) User Story? Hvordan arbejder man med Product Backlock? Hvordan arbejder man med Sprint Backlock? • Vi øver os på ”IT-casen”

Learning Objectives for Scrum Knowledge of Scrum basic process model § How to document and estimate customer requirements § How to turn these requirements into an operational format the developers can use to control their daily work § How to monitor and manage the development effort § (How to calculate team velocity, meaning how much work a team can handle in time-boxed period) § How to work in an iterative manner where software is build piece by piece

Scrum in a Nutshell Split your work into a list of small, concrete deliverables. § Sort the list by priority § Estimate the effort of each item Source: Kniberg ” KANBAN AND SCRUM – MAKING THE MOST OF BOTH”

Scrum in a Nutshell After each iteration § Optimize the release plan and update priorities in collaboration with the customer, based on insights gained by inspecting the release § Optimize the process by having a retrospective after each iteration. Source: Kniberg ” KANBAN AND SCRUM – MAKING THE MOST OF BOTH”

Product Backlog The agile product backlog in Scrum is a prioritized features list, containing short descriptions of all functionality desired in the product

The Product Backlog A prioritized list of everything that might be needed in the product: § Requirements, features etc. § Things that the customer wants, described using the customer’s terminology.

Product Backlog Item - Often called (user) story, or just PBI. Examples of user stories § As a user, I want to upload photos so that I can share photos with others. § As an administrator, I want to approve photos before they are posted so that I can make sure they are appropriate.

Product Backlog - Living document The Scrum Product Backlog is changed throughout the whole project. If needed, new requirements are added and existing requirements may be modified, defined in more detail or even deleted. Requirements are no longer frozen early on. Instead the final set of requirements within the Scrum Product Backlog is also developed iteratively, together with the resulting software. This is different to traditional requirements engineering but allows maximizing customer value and minimizes development effort.

Product Backlog - Different level of details The requirements in the Scrum Product Backlog have a different granularity. Only those requirements that shall be implemented during one of the next sprints are defined in greater detail and everything else is more coarse-grained. The simple reason for this is that it does not make sense to invest time and effort into the specification of these requirements, as most of these requirements will have changed anyway until implementation starts.

Product Backlog The Scrum Product Backlog is ordered All entries are prioritized and the Scrum Product Backlog is ordered. The Scrum Product Owner with the help of the Scrum Team does the prioritization. Added Value, Costs and Risks are the most common factors for prioritization. With this prioritization the Scrum Product Owner decides what should be done next.

Who is Responsible for Product Backlog? The Product Owner § Represents the stakeholders, i. e. the voice of the customer. § Is responsible for maximizing product value § Is responsible for managing the PBL: § Creating Product Backlog items (user stories) § Prioritizes the items in the Product Backlog § Ensuring the Development Team understands items to the level needed.

Scrum Roles Product Owner Responsible for the business value of the project Development Team Self-organizes to get the work done Scrum Master Ensures that the team is functional and productive

Scrum Master The Scrum Master is the process owner § Responsible for ensuring Scrum is understood and enacted § Helps the team perform at their highest level § Protector of the team (coach)

Scrum Meetings - Flow

Scrum Flow

User Stories User stories are short, simple descriptions of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system.

User Story § … is short, simple description of a feature told from the perspective of the person who desires the new capability (typically user or customer) § User stories can be written informally: Registered users can reset their password § Or use a bit more formal template As a registered user, I want to reset my password, so that I can get back into the site if I forget my password

Acceptance Criteria § Bring the project from ”It Works as Coded” to “It Works as Intended” § Are conditions that a story must satisfy to be accepted by a user, customer or other stakeholder (PO in Scrum) § Are a set of statements, each with a clear pass/fail result, that specify both functional and non-functional requirements § Functional example: When a user clicks on the ‘Reports’ dropdown, a list of available reports will be displayed. § Non-functional example: Form edit buttons will be blue, and Form workflow buttons will be green. Source: http: //www. seguetech. com/blog/2013/03/25/characteristics-good-agile-acceptance-criteria

Example User story: As an Administrator, I want to be able to create User Accounts so that I can grant users access to the system Acceptance Criteria 1. If I am an Administrator, I can create User Accounts. 2. I can create a User Account by entering the following information about the User: a. Name, b. Email address, c. Phone Number d. License Number (Power/Basic/None), e. Account Status (Active/Inactive), f. Reports to (from a list of "Active" Users) 3. I cannot assign a new User to report to an “Inactive” User 4. I cannot assign a new User to report to a User if it creates a cyclical relationship (e. g. , User 1 reports to User 2 who reports to User 1 5. The system notifies me that it sent an email to the new User's email address, containing a system-generated initial password and instructions for the person to log in and change their password. 6. I am able to verify with the intended recipient of the email that it was received. Source: http: //www. seguetech. com/blog/2013/03/25/characteristics-good-agile-acceptance-criteria

Så er det jeres tur! § Identificer og beskriv User Stories for ”IT-Casen” § Beskrives på formen AS a …, I want to …. , so that…… § Påfør Acceptence Criteria

Estimate

Agile Estimation Agile estimation is much about setting the expectations and about the time required to complete the software among the stakeholders, the team, and the organization’s management. If those expectations are not realistic from the beginning of the project, the stakeholders will not trust the team. Estimating is about reducing the uncertainty to a minimum, measuring the effort needed to complete the tasks at hand at the same time taking the complexity of the tasks into account. In order to have a basis for our estimation, we apply a range of tools and techniques that takes uncertainty, effort and complexity into account.

Estimation challenges § Ambiguous/changing requirements are hard to estimate. § Difficult to predict what exactly will be delivered when. § Estimating takes too long and we still don’t get it right. § Estimates are provided by the wrong people (not the ones doing the actual work). § Software projects are unique and ambiguous, hard to provide exact estimates. § Business customers promise unrealistic deadlines then tell the team to make it work. § Commitments are signed based on high level estimates. § Fixed Scope, Time, Budget! § “Estimates” are expected to NOT Change.

Estimation tips § § § Don't estimate alone Estimate in a range not in exact numbers Add some documentation to the estimate Make the triangulation (compare) with the user stories Use historical data for et estimate

Story Estimation Technique - Relative sizing The concept of relative sizing is to estimate the size of a function or user story based on the size of another one.

Story Estimation Technique - S, M, L and XL S, M, L and XXXXL § Each estimator have four cards S, M, L and XXXXL (epic) § Each estimator privately selects one card to represent their estimate for a story. All cards are revealed at the same time § If consensus, that will be the estimate § If not, discussion will lead to re-estimation until consensus

Story Estimation Technique - Planning Poker Planning poker is a full planning process that combines estimation with identifying the scope of the project and the tasks required to complete the project. Similar to relative sizing, planning poker is an estimating technique used to achieve consensus on work estimate. 1. Individual stories are presented for estimation. 2. After a period of discussion, each participant chooses from his own deck the numbered card that represents his estimate of how much work is involved in the story under discussion. 3. All estimates are kept private until each participant has chosen a card. 4. Finally, all estimates are revealed and discussion can begin again.

Sprint Backlog The sprint backlog is a list of tasks identified by the Scrum team to be completed during the Scrum sprint.

Sprint Backlog Within the Sprint Backlog all activities required to complete the committed entries from the Scrum Product Backlog are stored. All entries have to be estimated on a person-hour base in order to track progress and remaining efforts. The Sprint Backlog is a living artifact and is updated on a daily base. If a team member starts to work on an activity his name is recorded within the sprint backlog. New activities can be added to the Sprint Backlog during the Sprint. At the end of the day all remaining efforts are updated and this defines how much work is left until the Sprint Goal is reached. The Definition Of Done is used to decide if an item is done or not. The Sprint Backlog can be kept electronically within e. g. an Excel-Sheet or with cards on a task board. The latter has some advantages (e. g. transparency and easy access) but additional complexity if the Scrum Team is distributed over multiple sites.

Sprint Backlog § Contains committed stories negotiated between the team and the Product Owner during the Sprint Planning Meeting § Initial tasks are identified by the team during Sprint Planning Meeting § Team will discover additional tasks needed to meet the fixed scope commitment during Sprint execution

Which stories to include in sprint? Team decision based on: In some cases the time estimate for a story won’t be what the product owner expected. This may prompt him to change the importance of the story. Or change the scope of the story, which in turn will cause the team to re-estimate, etc Scope question example – “does this ‘delete user’ story include going through each pending transaction for that user and canceling it? ’” In some cases the answers will be surprising to the team, prompting them to change their estimates

Sprints Story As a online store owner, I want to Read (view) my products so that I can review what is current available on my site Splitting story into tasks (examples) 1. 2. 3. 4. 5. 6. Create database table Populate table with a few sample data Create select SQL script Create UI for viewing my products … Create automated functional tests for viewing functionality

Tasks § Stories Deliverable things at PO (business value) level § Tasks Non-deliverable things that PO doesn’t care about.

Sprint Backlog Format

Burndown Chart Tracking progress during sprint. § The graph shows, each day, a new estimate of how much work remains until the team is finished.

Literature Henrik Kniberg Scrum and XP from the Trenches: http: //www. infoq. com/minibooks/scrum-xp-from-thetrenches Pages : p. 1 -41 (Scrum Day 1) + 43 -71 (Scrum Day 2) http: //www. scrum. org/Portals/0/Documents/Scrum%20 Guid es/Scrum_Guide. pdf http: //scrumreferencecard. com/Scrum. Reference. Card. pdf Lynda http: //www. lynda. com/Business-Project-Managementtutorials/Agile-Project-Management/122428 -2. html http: //www. lynda. com/Business-Skills-tutorials/Managing. Project-Stakeholders/168242 -2. html