Scrum Crash Course

Scrum offers an alternative to conventional management practices. With the dynamics of business constantly evolving, management techniques have to evolve as well. Before you can implement Scrum, you need to learn more about how it works and the steps it entails. Here is an overview of what you will learn through our Scrum Crash Course:

Epics
Overarching Initiatives: If you think about building a piece of software or a website, this could represent an entire page. Stories are associated with Epics. A good epic is defined by all the stories that will accomplish the goal.

Tips: A good way to think of an Epic is as a set of features that would accomplish a specific goal for the project. When thinking of epics, you may think of milestones. Each project is different, so it will take some practice to get good at breaking projects down into meaningful parts.

Stories
A story is like a task but is told as a story.
For example:
“As a user, I can update my password and save it to my account”
Remember, this is about good communication, so try to include images and artifacts to help your teammates understand the intent of the story.
Also, a good story answers all relevant questions upfront. A scrum master and project manager will help with this.

Sprint Planning
A sprint is a block of time. In our case, we work in two-week increments (also known as iterations). Before we kick off a two-week sprint, our scrum team assigned to the project will sit together and pull projects from the icebox and enter them into the backlog to be worked on.

Use the effort points allocated to each story as a mechanism to understand how much work your team may accomplish within a two-week sprint. The sum of the story points your team is able to accomplish within a sprint is called Velocity.

The Sprint
The sprint a sacred block of time that is to be projected at all costs. Once the work has been agreed upon, it is up to the team and the scrum master to work together to achieve the sprint. Teams use meetings, like “The Daily Standup”, and communication tools like Slack to warn each other in case there is a chance that some task will not be completed. The goal of the sprint is to exact all of the work they had agreed upon to either meet or exceed their target velocity.

The Daily Standup
When your team is assembled, and wherever possible, a standup is a 10 to 15-minute block of time where you stand with your team and each person gets a minute or so to discuss:

  1. What they accomplished yesterday
  2. What they hope to accomplish today
  3. Is there anything blocking them

Tip: DO NOT FIND A SOLUTION. Stand-ups tend to take up too much time when we hear a problem and try to find a solution for the problem during the standup. Scrum Masters have to keep the team on task. If a blocker arises or a few team members need to collaborate on something, kindly request that those conversations take place after the standup.

Blockers
A blocker is generally a reference to something that is preventing work from being done. This could be missing information, missing technology requirements, another story/epic that needs to be done first, design artifact or even a client meeting that has not occurred yet.

Dealing with Blockers
Blockers occur often and vary from case to case but you have to overcome them to keep your team moving. There is no one way to deal with blockers except to communicate clearly. Ask good questions that get to the root of what needs to be solved and have laser focus on solving exactly that. Once you feel the blocker has been eliminated, confirm with your team that they are able to move forward.

An enemy of success is assumption.

Velocity
Velocity is the sum of effort points your team is able to accomplish within a given sprint. It is part of the Scrum Master’s agenda to work with the team to achieve the highest velocity possible. Note that there will be certain things that affect your team’s velocity, for example vacations.

The Backlog
The backlog is a set of epics and or stories in order of highest value or customer impact. A backlog should be groomed regularly.

Steps for Grooming a Backlog

  1. There are times our teammates may not be using the backlog to record progress on a story. Encourage them to use the tools provided to your team to make sure stories are kept up to date.
  2. The backlog is sorted by the most important work first, so make sure all the epics and stories are in order.
  3. Make sure stories are well written and provide as much meaning as possible. Think if someone was looking at the story for the first time, can they sort out what needs to be done without needing to ask you a question?
  4. Remove or otherwise delete stuff that is just not going to get done or is redundant.

Sizing
Stories need to be sized for effort. We use a scale of 1,2,3,5 and 8. To size a story, sit with the scrum team assigned to the backlog and go through the stories and size them with the team. Get everyone involved in contributing to the sizing. Your teammates have different experience and visibility into the work you do.

Effort and Points
Effort is not exactly associated with how much time something will take, but the higher the point value allocated to a given task, the more tasking it will be on the team. A good rule of thumb is that if a story scores over 5 points, it should be broken down into more stories.

With Scrum, you can enhance the efficiency and productivity of your team and also make sure that work is completed on time, without conflict, and without compromising on quality. Scrum offers the ideal framework for modern businesses to improve their operations and achieve their goals.

Scaling Your Team

When developing a software or program, you would be familiar with the concept of scaling. The idea is to keep adding elements as and when required, usually when the program starts becoming more complex to handle using the tools you have on hand now. The same concept can be applied to your software development team. Here’s how you can go about it:

  • Start by coming up with your best idea. Yes, this is the right way to go about scaling your team. When you have few people around you, you will be able to think a lot more clearly, and hence now is the best time to brainstorm and come up with the idea that will take you to the top. As they say, too many cooks spoil the broth. When you bring more people on board, you will get a structure and a great system working for you, but the time to think would be long gone.
  • Hiring the right people is more important than hiring the most qualified or experienced people. As mentioned, initially you don’t need much of a structure, but as the team grows, you need to assign goals and roles to each member. This is why every member you bring on should fulfill a role, and not just be a passenger.
  • When bringing new members on board, do it in stages. Initially, 2 to 4 people are fine. In the next stage, bring the total up to 9, max. Then, you can take it up to 15 and that’s where you have to stop. Assigning more than 15 developers to a project can be overwhelming for everyone and many great ideas might get lost in the noise. You have to weather the transition between stages and handle any crisis which emerges.
  • As mentioned, assigning roles is important. Take it a step further by creating different teams which take care of different parts of the project. The idea is to have one group of people focusing on one thing so that they can give it their best shot. This is where you can benefit from specialization.
  • Cohesion and communication is the key to making scaling work. You have to be clear about your plans from the outset and keep everyone in the loop. Only bring on new people if you need and if there are any issues with the progress of the software, inform everyone involved without delay.

These are some tips you can follow to scale your team as your software project moves along. This will ensure the entire process is seamless and that you don’t have to bear any hassle