lighttangent

Loading

Blog

scrum

The Sprint: Turning Ideas into Value

Sprints are the core of Scrum, helping turn ideas into real results. They are short, fixed-length periods, usually a month or less, that start immediately after the previous Sprint ends.

During Sprints, the team works on all tasks needed to achieve the Product Goal, including:

  • Sprint Planning
  • Daily Scrums
  • Sprint Review
  • Sprint Retrospective
  • In a Sprint:

No changes are made that could risk the Sprint Goal. Quality stays consistent. The Product Backlog is updated as needed. The scope can be clarified and renegotiated with the Product Owner as new information comes in.

Sprints help maintain predictability by ensuring regular checks and adjustments toward the Product Goal at least once a month. If a Sprint is too long, the Goal might become outdated, complexity might rise, and risks could increase. Shorter Sprints allow for more learning and reduce risk by limiting the time and effort involved. Each Sprint is like a small project.

A Sprint can be canceled if its Goal becomes irrelevant. Only the Product Owner can cancel a Sprint.

scrum

What are Scrum Events?

Scrum comprises five key events, each serving a unique purpose and involving specific participants:

  • The Sprint
  • Sprint Planning
  • Daily Scrum
  • Sprint Review
  • Sprint Retrospective

Purpose of Scrum Events

  • Sprint: All work in Scrum is done within a timebox called a Sprint, which enables feedback loops.
  • Sprint Planning: This planning session occurs before the Sprint starts. Developers outline the work they intend to complete during the Sprint.
  • Daily Scrum: Held daily, this event allows Developers to inspect their progress toward the Sprint Goal.
  • Sprint Review: At the end of the Sprint, the Scrum Team meets with stakeholders to demonstrate what they have accomplished and to receive feedback.
  • Sprint Retrospective: Toward the end of the Sprint, the Scrum Team gathers to discuss the Sprint’s progress and identify improvements for the next Sprint.

Who Participates in the Scrum Events?

  • Sprint: Scrum Team
  • Sprint Planning: Scrum Team, led by the Product Owner
  • Daily Scrum: Development Team (Product Owner and Scrum Master may optionally attend)
  • Sprint Review: Scrum Team, Stakeholders, Business Team
  • Sprint Retrospective: Scrum Team, led by the Scrum Master

How Much Time Should We Spend on Scrum Events?

  • Sprint: Maximum of 4 weeks, typically 2 weeks
  • Sprint Planning: 2 hours for a 2-week sprint. Tip: Consider two 1-hour Sprint Planning sessions during the sprint (e.g., if the sprint starts on Wednesday, hold sessions on the following Monday and Thursday).
  • Daily Scrum: 15 minutes Tip: Keep the Daily Scrum to 15 minutes, but allow an additional 15 minutes for detailed discussions, especially for teams in different time zones.
  • Sprint Review: 1 hour for a 2-week sprint
  • Sprint Retrospective: 1 hour for a 2-week sprint

(These time recommendations are based on practical experience.)

Tip – Which is the Most Important Event in Scrum?

In interviews, the simple answer is “all of them.” However, if you must choose one besides Sprint, it often depends on your organization’s context. I would say the Daily Scrum is crucial, as it’s a daily meeting where developers discuss impediments, open questions, and clarifications. This collaboration is essential in our fast-changing world, helping the team stay updated and on track to achieve the Sprint Goal.

Tip: Why Does Scrum Have Events Instead of Ceremonies?

Scrum uses the term “events” instead of “ceremonies.” Although you might hear the term ceremonies in discussions, it is incorrect in the context of Scrum. The distinction is important: ceremonies follow a fixed process without alterations, whereas events in Scrum are designed to be adaptable. Processes within these events can be modified based on prior learnings and team-specific contexts. Each organization’s way of working can vary from team to team, allowing them to adjust processes to better fit their unique needs and experiences.

scrum

What is Daily Scrum?

The term “Daily Scrum” comes from the Scrum Framework. Teams following Scrum do call it Daily Stand Up and that’s wrong. If your team follows Scrum, the event is “Daily Scrum”. Daily Stand up is a word that comes from agile practices but for Scrum, it is only “Daily Scrum”.

Purpose of Daily Scrum

To inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work.

Tip – Does your Product Owner (PO) share the Sprint Goal before the start of the new Sprint, if not time to ask the PO to share the Product Goal. If you are a Product Owner (PO) and do not create a Sprint Goal, create one on your next sprint.

What happens in a Daily Scrum

This is a 15-minute event for the Developers of the Scrum Team. The Developers can select whatever structure and techniques they want, as long as their Daily Scrum focuses on progress toward the Sprint Goal and produces an actionable plan for the next work day. This creates focus and improves self-management.

Who should attend the Daily Scrum?

The Daily Scrum is for the developers. If the Product Owner or Scrum Master actively works on items in the Sprint Backlog, they participate as Developers.

Tip – It is fine if the Scrum Master or Product Owner joins the Daily Scrum.

The benefit of Daily Scrum

Improve communications, identify impediments, promote quick decision-making, and consequently eliminate the need for other meetings. Developers do adjust their plans.

scrum

What is a Story Point?

A Story Point is a unit of measure for expressing the overall size of a User Story, feature, or piece of work. It is a relative measure of the size of a user story, and there is no set formula for defining this size.

Story Point Estimation – How to Estimate Story Points

Story Point Estimation considers the effort involved in developing the feature, its complexity, and its inherent risk. It is done collaboratively by the team, not by a single individual. Usually, Story Point Estimation is conducted during the Sprint Planning event. However, if the Product Owner has prioritized stories for the next sprint, the estimation can be done during Sprint Refinement sessions as well, saving time during Sprint Planning as the team discusses the user stories.

Story Point Estimation Techniques

Here are various Story Point Estimation techniques used by teams:

Planning Poker

Planning Poker follows the Fibonacci Sequence for User Story estimation. The Product Owner explains the User Story, and every team member selects a number on a card or planning poker tool. The number with the maximum votes is the finalized estimate.

What is Fibonacci Sequence?

It is a mathematical sequence where each number is the sum of the two that precede it.  Fibonacci sequence is as follows, it starts with 0. It is as follows – 0,1,2,3,5,8,13,21

Tip – Don’t spend ample time on story pointing exercise, it is just an estimate.

T-Shirt Size Estimation

This technique uses T-shirt sizes to estimate User Stories. The sizes are typically Small, Medium, Large, and Extra Large.

Flying Fingers

In this technique, the team reads a story and discusses it with the Product Owner for any clarifications. Then, each member puts one hand behind their back and holds up the number of fingers corresponding to the points they think the story deserves. On a count of three, everyone shows their fingers. If everyone shows the same number, the estimate is confirmed. For any disagreement, a follow-up discussion occurs to agree on a common number.

Conclusion

Story Point Estimation is common in teams following Scrum, even though Scrum does not explicitly mention Story Points. It is a complementary practice followed by many teams. Most Scrum teams use Planning Poker for Story Point Estimation, hence following the Fibonacci Sequence. The purpose of this article is to provide an understanding of Story Points and the estimation techniques used by teams. Estimation is essential as every organization needs a high-level estimation for planning and budgeting. However, it is prudent not to spend unnecessary time on estimating stories rather than focusing on actual work.

Agile

What is a User Story?

A User Story is a narrative describing a system feature from the user’s perspective. It serves as a placeholder for future discussions between developers and business stakeholders. Typically, a user story is written on an index card, which is sufficient for facilitating a conversation. It is not a detailed requirement but is intended to evolve as discussions progress and requirements become clearer. If a requirement is deemed unnecessary, the user story can be discarded. A user story’s simplicity and lack of detail make it manageable and estimable.

Example of a User Story –

Here is a User Story related to a bank –

Loan Application

As a bank customer, I want to apply for a loan online so that I can avoid visiting the branch in person and conveniently manage my finances from home.

Here is a User Story for a pharmaceutical industry –

Prescription Refill

As a patient, I want to request a prescription refill online so that I can conveniently get my medication without needing to visit the pharmacy in person.

Here is a User Story for a construction company–

Material Inventory Management

As a site supervisor, I want to track the inventory of construction materials so that I can ensure we have the necessary supplies and avoid delays due to shortages.

Pointers on writing a story

One of the approaches to writing a User Story is to follow the INVEST guideline.

  • I – Independent, every user story needs to be independent of each other.
  • N – Negotiable, requirements discussion and negotiation between the developers and business stakeholders.
  • V – Valuable, clear, and quantifiable value to business
  • E – Estimable, enough details for developers to estimate
  • S – Small, small enough that it can be worked by 1-2 developers
  • T – Testable, for business to test the work done.

Conclusion

User Story is not a replacement for requirement-gathering documentation, it is a narrative for discussion between developers and business persons.

User Story is not part of Scrum though it has been widely used in Scrum. If you refer the Scrum Guide, you will find the word “work” and not User Story.

User Story is also not part of Kanban, if you refer the Kanban guide – you will find the word ” work items” and not user story.