Scrum development process is a great way to deliver projects and software, but also a little bit of a challenge for those not used to it.
Here’s an 8 Step Guide that will Help You Get Started
1. Define team roles
Team roles should be divided as follows: Scrum Master, Developer/Engineer, QA/Tester. It is important to highlight here that each member of the team must have one role only. Team members cannot assume more than one role at the same time.
In addition, if any team member assumes a different role other than his/her own during a Sprint Review meeting or other kinds of event, then that person automatically loses all privileges granted by being part of the team throughout this Sprint season (i.e. Developers can’t help QA, or Scrum Master cannot contribute to code reviews).
2. Define team goals
This is the most important part of the process. Team goals should be specific, challenging, and measurable. The more challenging they are, the more sense of achievement your team will get at the end of each Sprint! Here’s an example that shows how you can define your team goals: “By next Sprint Season our goal is to reduce bugs in order to increase customer satisfaction”.
3. Divide tasks among team members
Your team might already have a set of predefined stand-up meetings (daily, weekly, etc.) so this step will consist of updating every member on what he/she should work on until the next meeting. Once you have a set of tasks defined, it’s time to distribute them among your team members.
4. Estimate task’s size and complexity
Estimating is important because it will let you know how much time each task needs to be completed. Without estimating, your Sprint will take way longer than necessary and there is no point in doing that since the whole idea behind it is delivering value as fast as possible! Don’t forget that you can modify/improve your estimates during the Sprint just in case something changes.
Also, it’s always better to overestimate for two reasons:
play safe
encouraging people to look at every Task critically since they’ll think “Hey this task maybe take us more than 5 hours so let’s cut some corners and we can deliver it faster instead of taking all 5 hours”.
5. Why is that useful?
before the Sprint planning, the whole Team must agree on what they want to accomplish. Each Task in there must be estimated and everyone should try their best to commit to it once they finish it. If a portion of your plan will not be finished by the end of the Sprint, you’ll fall behind schedule and miss out on some functionalities! Agreeing on estimates prior to beginning a certain task (and giving yourself enough time for it) reduces the chance of missing any deliverables significantly – don’t forget that we’re trying our best here to avoid context switching at all costs and this article is only focusing on advisable practices during the Sprint planning part.
6. How do we estimate?
Although this question belongs to the Sprint Planning part, I’ve decided to place it at the end because I consider it a very important topic. If you’re planning on using Story Points for estimating your Tasks/Features/User Stories then this will be rather easy – if not, then feel free to choose any other task-estimating technique that would help you achieve the desired results. There are a few articles out there where people describe how they do Scrum and how they role it along with their organization so I’ll leave all of them for you to read and pick up something from each of them 😉
7. Point Scale
Using the 7-point Scrum scale – however, I think it’s not suitable for everyone/every team so this is why I will describe both of them. Also, note that if you are planning on using larger story point scales then be prepared to have more stories being done in one Sprint or having smaller Sprints.
It’s quite simple to use and easy to understand. We all know that 1,2,3 are very small stories, 4-6 are bigger ones and 7-8 are bigger again. This makes it so much easier when you first start using Scrum as having only 3 sizes allows your team to break down work into smaller parts early on during the first Sprint planning meeting so they don’t block other developers by doing too much at once.
8. Item limits
The biggest problem with this scale is that people will not use all 8 Story Points. They start off at one point because it seems too big, then they go over to 4 points, then back to 2-3, and so on. The second biggest problem with this scale is that if you run out of ideas during the planning meeting (we call them Sprints) you might never get around to finishing them or at least not doing more than 3 stories per Sprint.
Estimating is also a good way to see how much work you can take on. Let’s say there are five people in your team and they estimate 10 hours per Sprint. That means the team is able to accomplish 50 hours’ worth of work per Sprint!
On the other hand, if all tasks take 15 hours then that means only 30 total hours will be completed which is lower than usual for most teams. Keep this in mind when planning out your Task list because oftentimes Sprints get filled up really quickly with Tasks and not everybody might be asked to do what they like; think about who would enjoy doing what kind of task before assigning anything.
