Scrum process experience at GBF
What is Scrum
Scrum is an agile project management framework mainly used for software development. It describes an iterative and incremental approach to project work. Scrum’s main goal is to meet the needs of the consumer by fostering a culture of open communication, shared accountability, and quality improvement.
Key Benefits of Scrum
- Quicker release of the useable product to users and customers
- Higher quality and productivity
- Lower costs
- Greater ability to incorporate changes as they occur
- Better employee morale
- Better user satisfaction
- Being able to complete complex projects that previously could not be done
GBF Scrum Methodology and Process
Scrum is indeed the advancement of Agile Management. Scrum methodology is based on a series of very specific procedures and functions that must be followed during the software development process. It’s a versatile approach that rewards product team members who apply the 12 agile concepts in a way that everybody agrees on.
Scrum is carried out in small, recurrent blocks known as Sprints, which normally last between 2 to 4 weeks and are used for feedback and reflection. Each Sprint is a self-contained unit, delivering a complete result, a variant of the final product, which must be delivered to the client with the least amount of effort possible when requested.
A collection of objectives/requirements that make up the project plan serves as the starting point for the operation. The project’s client prioritizes these goals based on a combination of value and cost; this is how iterations and subsequent deliveries are calculated.
On the other hand, the market demands quality, speed, and low costs, necessitating a company’s agility and flexibility in product development in order to achieve short development cycles that can satisfy consumer demand without compromising the quality of the end product. It’s a simple methodology to incorporate, and it’s very popular for the fast results it gets.
Scrum Workflow
Different Scrum Roles
Each of these roles have a clearly defined set of responsibilities that enable everyone to perform their tasks efficiently and help ensure the project’s success.
Product Owner
Accountability
Represents the end customer and/or other stakeholders and is responsible for maximizing the value of the product by ensuring that the right work is done at the right time.
Responsibilities
- Managing the Scrum Product Backlog
- Release Management
- Checking and accepting the Sprint results during the Sprint review session
- Product owner can not introduce new or re-prioritize requirements of a sprint once
Scrum Master
Accountability
Ensures everyone follows the practices prescribed by Scrum.
Responsibilities
- Prepare and facilitate the various Scrum meetings
- Remove impediments for the Scrum Team
- Ensure efficient communication between the Scrum Team and the Scrum Product Owner
- Guard the Scrum Team from external requests and disruption
Scrum Meetings
These meetings provide the framework for teams to get work done in a structured manner, help to set expectations, empower the team to collaborate effectively, and ultimately drive results.
Backlog Refinement Meeting
Why
Purpose:
The product owner is prepared, meaning that User stories for the coming 2 sprints should be detailed and understood
Who
Owner:
Product Owner
Required Attendees:
Scrum Master, Product Owner, and devs as requested
What
Inputs:
Product backlog tool with a list of prioritized stories, not yet estimated.
Output:
- Enough detail per user story
- Acceptance criteria per user story
- Estimation per user story
When
Schedule:
Weekly or as requested
Duration:
~1-2 hours per meeting
Sprint Planning Meeting
Why
Purpose:
Define the goal of next sprint (What needs to be done / How value can be added to the product)
Select user stories that can be done in the next sprint.
Define subtasks (How to execute the work).
Who
Owner:
Scrum Master
Required Attendees:
Scrum Team
What
Inputs:
Product owners propose the highest priority user stories to the developers
Output:
- Everyone should understand the user stories explained by the product owner
- Based on the capacity and performance of previous sprints the developers select the user stories for the next sprint (the sprint backlog)
When
Schedule:
As early as possible before the start of the next sprint
Duration:
- 4 wk sprints: Max 8 hours
- 2 wk sprints: Max 4 hours
~1-2 hours to define the goal and select user stories to ether with Product Owner
~2-6 hours with the developers to decide how to execute per item
Daily Standup Meeting
Why
Purpose:
- To commit ownership of tasks by the Scrum team
- Identify roadblocks
Who
Owner:
Scrum Master
Required Attendees:
Scrum Team
What
Inputs:
- What did you do yesterday?
- What are you going to do today?
- What is keeping you from accomplishing tasks?
Output:
Move tasks cards on the Scrum board from one state to another
When
Schedule:
Approximately 9:00 AM
Duration and Cadence:
~15 minutes, daily excluding the first and last day of a sprint
Sprint Review Meeting
Why
Purpose:
- Demonstrate the accomplishments of the sprint
- Ensure that all requirements and acceptance criteria were met and are acceptable to the Product Owner
Who
Owner:
Product owner
Required Attendees:
Scrum Team, Product Owner, and Other Stakeholders
What
Inputs:
- What did you do yesterday?
- What are you going to do today?
- What is keeping you from accomplishing tasks?
Output:
Move tasks cards on the Scrum board from one state to another
When
Inputs:
Updated sprint backlog with list of stories completed during the last sprint
Output:
- Team understanding via demonstration of the development accomplishments
- Change Requests may be generated for future sprints. The next sprint review meeting date and time is planned
How to Estimate Work Using User Stories
Story points are units of measure for expressing an estimate of the overall effort required to fully implement a product backlog item. Teams assign story points relative to work complexity, the amount of work, and risk or uncertainty. For example, 1 staff can do approx 14-20 story points per day.
Estimation is hard. For software developers, it’s the most difficult–aspect of the job. It must help product owners make decisions that affect the business. With all that at stake, it’s no wonder everyone is becoming emotional about it. But that’s a mistake. Agile estimation is just that: an estimate.
How do we make agile estimates as accurate as possible?
Collaborate with the product owner. The product owner is tasked with prioritizing the backlog –the ordered list of work that contains short descriptions of all desired features and fixes for a product. Estimation can give the product owner new insiGht into the level of effort for each work item, which then feeds back into their assessment of each item’s relative priority.
When the developers begin their estimation process, questions usually arise about requirements and user stories. And that’s good: those questions help the entire team understand the work more fully. For product owners specifically, breaking down work items into granular pieces and estimates via story points helps them prioritize all (and potentially hidden!) areas of work.
User Stories
User stories are part of an agile approach that helps shift the focus from writing about requirements to talking about them. All agile user stories include a written sentence or two and, more importantly, a series of conversations about the desired functionality.
What is a user story?
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. They typically follow a simple template:
As a < type of user >, I want < some goal > so that < some reason >.
They are often written on sticky notes and arranged on walls or tables to facilitate planning and discussion. As such, they strongly shift the focus from writing about features to discussing them. In fact, these discussions are more important than whatever text is written.
Who writes user stories?
Anyone can write user stories. It’s the product owner’s responsibility to make sure a product backlog of file user stories exists, but that doesn’t mean that the product owner is the one who writes them. Over the course of a good agile project, you should expect to have user story examples written by each team member.
Also, note that who writes a user story is far less important than who is involved in the discussions of it.
How to write user stories?
Start your stories with “As a” to identify the user.
- Ensure your stories describe a feature.
- It details the user’s need and is usually written as “I want”.
- Lastly, stories should explain the purpose.
- It details the benefit(s) to the user and is usually written as ‘so that’.
When are user stories written?
User stories are written throughout the agile project. Usually, a story-writing workshop is held near the start of the agile project. Everyone on the team participates with the goal of creating a product backlog that fully describes the functionality to be added over the course of the project or a three- to six-month release cycle within it.
Some of these agile user stories will undoubtedly be epics. Epics will later be decomposed into smaller stories that fit more readily into a sin le iteration. Additionally, new stories can be written and added to the product backlog at any time and by anyone.
Samples of a user story
One of the benefits of agile user stories is that they can be written at varying levels of detail. We can write a user story to cover lar e amounts of functionality. These lar e user stories are generally known as epics. Here is an epic agile user story example from a desktop backup product:
- As a user, I can back up my entire hard drive.
Because an epic is generally too lar e for an agile team to complete in one iteration, it is split into multiple smaller user stories before it is worked on. The epic above could be split into dozens (or possibly hundreds), including these two:
- As a power user, I can specify files or folders to backup based on file size, date created, and date modified.
- As a user, I can indicate folders not to backup so that my backup drive isn’t filled up with things I don’t need to be saved.
How can details be added
Detail can be added to user stories in two ways:
- By splitting a user story into multiple, smaller user stories.
- By adding “conditions of satisfaction.”
The condition of satisfaction is simply a high-level acceptance test that will be true after the user story is complete. Consider the following as another user story example:
As a business development manager, I want to select a holiday season to be used when reviewing the performance of past advertising campaigns so that I can identify profitable ones.
Detail could be added to that user story example by adding the following conditions of satisfaction:
- Make sure it works with major retail holidays: Christmas, Easter, President’s Day, Mother’s Day, Father’s Day, Labor Day, New Year’s Day.
- Support holidays that span two calendar years (none span three).
- Holiday seasons can be set from one holiday to the next (such as Thanksgiving to Christmas).
- Holiday seasons can be set to be a number of days prior to the holiday.
Contact us for more information.
