ScrumAA Blog & Articles

• Scrum Sprint
• Cancelling a Sprint
• Sprint Goal

Scrum Sprint

So what is the definition of a Scrum Sprint? According to the Scrum Guide, the heart of Scrum is a Sprint, a time-box of one month or less during which a “Done”, useable, and potentially releasable product Increment is created. Sprints have consistent durations throughout a development effort. A new Sprint starts immediately after the conclusion of the previous Sprint.

Scrum Sprints contain and consist of the Sprint Planning, Daily Scrums, the development work, the Sprint Review, and the Sprint Retrospective.

During the Scrum Sprint:

1. No changes are made that would endanger the Sprint Goal;
2. Quality goals do not decrease; and,
3. Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned.

Each Scrum Sprint may be considered a project with no more than a one-month horizon. Like projects, Sprints are used to accomplish something. Each Sprint has a goal of what is to be built, a design and flexible plan that will guide building it, the work, and the resultant product increment.

Scrum Sprints are limited to one calendar month. When a Sprint’s horizon is too long the definition of what is being built may change, complexity may rise, and risk may increase. Sprints enable predictability by ensuring inspection and adaptation of progress toward a Sprint Goal at least every calendar month. Sprints also limit risk to one calendar month of cost.

Cancelling a Sprint

A Sprint can be cancelled before the Sprint time-box is over. Only the Product Owner has the authority to cancel the Sprint, although he or she may do so under influence from the stakeholders, the Development Team, or the Scrum Master.

A Sprint would be cancelled if the Sprint Goal becomes obsolete. This might occur if the company changes direction or if market or technology conditions change. In general, a Sprint should be cancelled if it no longer makes sense given the circumstances. But, due to the short duration of Sprints, cancellation rarely makes sense.

When a Sprint is cancelled, any completed and “Done” Product Backlog items are reviewed. If part of the work is potentially releasable, the Product Owner typically accepts it. All incomplete Product Backlog Items are re-estimated and put back on the Product Backlog. The work done on them depreciates quickly and must be frequently re-estimated.

Sprint cancellations consume resources, since everyone regroups in another Sprint Planning to start another Sprint. Sprint cancellations are often traumatic to the Scrum Team, and are very uncommon.

Sprint Goal

The Sprint Goal is an objective set for the Sprint that can be met through the implementation of Product Backlog. It provides guidance to the Development Team on why it is building the Increment. It is created during the Sprint Planning meeting. The Sprint Goal gives the Development Team some flexibility regarding the functionality implemented within the Sprint. The selected Product Backlog items deliver one coherent function, which can be the Sprint Goal. The Sprint Goal can be any other coherence that causes the Development Team to work together rather than on separate initiatives.

As the Development Team works, it keeps the Sprint Goal in mind. In order to satisfy the Sprint Goal, it implements functionality and technology. If the work turns out to be different than the Development Team expected, they collaborate with the Product Owner to negotiate the scope of Sprint Backlog within the Sprint.

ScrumAA articles are derived from the Scrum Guide

Go back to the blog’s page for more articles.

You can also check our Wiki page for more additional information regarding Scrum knowledge in general and definitions by clicking this link.

• User Story Definition
• User Story Template: Role-Action-Benefit
• User Story Examples
• The 3 C’s (Card, Conversion, Confirmation) of User Stories
• How to Write Good User Story with INVEST Guidelines

User Story Definition

So what is a User Story? In software development and product management, a User Story is an informal, natural language description of one or more features of a software system. User stories are often written from the perspective of an end user or user of a system. They are often recorded on index cards, on Post-it notes, or digitally in project management software Depending on the project, user stories may be written by various stakeholders including clients, users, managers, or development team members.

User stories are a type of boundary object. They facilitate sense making and communication; that is, they help software teams organize their understanding of the system and its context. [1]

User Story Template: Role-Action-Benefit

A User story only capture the essential elements of a requirement in the format “As a <who> I want <what> so that <benefit>”:

As a Role {Who}, I want to Action {What}, (so that Benefit {Why})

Role – The user should be an actual human who interacts with the system.

• Be as specific as possible
• The development team is NOT a user

Action – The behavior of the system should be written as an action.

• Usually unique for each User Story
• The “system” is implied and does not get written in the story
• Active voice, not passive voice (“I can be notified”)

Benefits – The benefit should be a real-world result that is non-functional or external to the system.

• Many stories may share the same benefit statement.
• The benefit may be for other users or customers, not just for the user in the story [2]

User Story Examples

As <a recruiter> I can <post new jobs> so that <applicants can find those jobs via search>

As <a job seeker> I can <limit who sees my resume> so that <I have privacy>

The 3 C’s (Card, Conversion, Confirmation) of User Stories

1. Card – a written description of the story used for planning and estimation.
2. Conversation – Discuss your ideas with others. Let them ask lots of questions. Work together to come up with ideal solutions. The goal is to build shared understanding.
3. Confirmation – Work towards agreement on what to build. Record that agreement as a set of confirmation tests.

How to Write Good User Story with INVEST Guidelines

The acronym INVEST helps to remember a widely accepted set of criteria, or checklist, to assess the quality of a user story. If the story fails to meet one of these criteria, the team may want to reword it, or even consider a rewrite (which often translates into physically tearing up the old story card and writing a new one).

I – Independent

Each User Story should represent a distinct and independent set of business value such that, were it released on its own, it would deliver incremental value over the previous state.

N – Negotiable

While the end-goal may be clearly described, the methods by which that goal is achieved should be negotiable – between the Product Owner and the Development Team, the Product Owner and the Customer, or any other involved stakeholders – so as to prevent unrealistic constraints on the feature or functionality.

V – Valuable

The business value of any User Story should be readily recognizable by reading the story, and each story should represent some sort of value to a specific user type.

E – Estimable

We must have enough information that we can properly size a story so that we may properly plan and commit to our work. (But no more!)

S – Small

User Stories should be small enough that they are able to be completed within a sprint.

T – Testable

All members of the team need a clear and precise way to verify whether or not a User Story has been completed

More articles from ScrumAA can be found here

Also check out Wikipedia for more information

References

[1] https://en.wikipedia.org/wiki/User_story

What is the Scrum Framework

The Scrum Framework in Scrum, is the prescribed events that are used to create regularity. All events are time-boxed events, such that every event has a maximum duration. The events are described more elaborately below.

Sprint

The heart of Scrum is a Sprint, a time-box of two weeks or one month during which a potentially releasable product increment is created. A new Sprint starts immediately after the conclusion of the previous Sprint. Sprints consist of the Sprint planning, daily scrums, the development work, the Sprint review, and the Sprint retrospective.

Sprint planning

The work to be performed in the Sprint is planned collaboratively by the Scrum Team.

Daily Scrum Meeting

This is a 15-minute time-boxed event for the Scrum Team to synchronize the activities and create a plan for that day.

Sprint Review

This is held at the end of the Sprint to inspect the Increment and make changes to the Product Backlog, if needed.

Sprint Retrospective

Retrospective occurs after the Sprint Review and prior to the next Sprint Planning. In this meeting, the Scrum Team is to inspect itself and create a plan for improvements to be enacted during the subsequent Sprint.

More articles from ScrumAA can be found here

Reference

https://www.scrum.org/resources/what-is-a-sprint-in-scrum

Structure of the Scrum Team

The Scrum team includes the:

• Product Owner
• Scrum Master, and
• Development team

The team share different tasks and responsibilities related to the delivery of the product. Each role are closely inter-related. It is recommended for Scrum team members work together in the same location whenever possible. Let’s take a look at each of these roles in terms of their responsibilities, authority, and characteristics.

Product Owner

The Product Owner is the Team member who knows what the customer wants and the relative business value of those wants. He or she can then translate the customer’s wants and values back to the Scrum team. The Product Owner must know the business case for the product and what features the customers’ wants. He must be available to consult with the team to make sure they are correctly implementing the product vision. Most importantly, he must have the authority to make all decisions necessary to complete the project, in other words, the Product Owner is responsible for managing the Product Backlog which includes:

1. Expressing Product Backlog items clearly.
2. Ordering the Product Backlog items to best achieve goals and missions.
3. Optimizing the value of the work the Team performs.
4. Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Team will work on further.
5. Ensuring that the Team understands items in the Product Backlog to the level needed.

Scrum Master

The scrum master help to keep the team accountable to their commitments to the business and also remove any roadblocks that might impede the team’s productivity. They met with the team on a regular basis to review work and deliverables, most often in a weekly cadence. The role of a scrum master is to coach and motivate team member, not enforce rules to them. The role of a scrum master includes:

1. Ensure the process run smoothly
2. Remove obstacles that impact productivity
3. Organize the critical events and meeting

Development Team

Development Teams are structured and empowered by the organization to organize and manage their own work. The resulting synergy optimizes the Development Team’s overall efficiency and effectiveness. Development Teams have the following characteristics:

1. They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality;
2. Development Teams are cross-functional, with all the skills as a team necessary to create a product Increment;
3. Scrum recognizes no titles for Development Team members, regardless of the work being performed by the person;
4. Scrum recognizes no sub-teams in the Development Team, regardless of domains that need to be addressed like testing, architecture, operations or business analysis; and,
5. Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole.

ScrumAA articles are derived from the Scrum Guide

This article, due to it’s importance, was copied entirely from here

Go back to the blog’s page for more articles

ScrumAA Articles: Why Scrum?

Author: ScrumAA

1. Scrum is an iterative and incremental agile software development methodology for managing product development.
2. It defines “a flexible, holistic product development strategy where a development team works as a unit to reach a common goal”, challenges assumptions of the “traditional, sequential approach” to product development
3. Scrum enables teams to self-organize by encouraging physical co-location or close online collaboration of all team members, as well as daily face-to-face communication among all team members and disciplines in the project.

ScrumAA articles are derived from the Scrum Guide

Go back to the blog’s page for more articles