If you’re not 100% sure how to get started with Scrum, then you've come to the right place. An effective Scrum process can get your teams a long way, if your initial steps are in line with all the Scrum ceremonies. Here's a guide to implementing Agile with Scrum and the reasons to do so at the first place.
The Benefits of Adopting Agile Scrum
During the last decade, agile has proven its ability to help many organizations manage constantly changing priorities and improve project visibility. It's also closely linked with greater business alignment, faster time to market, and increased team productivity. 26% of organizations participating in 2020’s Annual State of Agile Survey even noted that agile helped them reduce project cost by 15%. Because Agile intends to deliver the business value constantly and at regular intervals, it has a positive impact
The idea of Agile transformation may be tempting, but it's clearly not for everyone. We always recommend to start looking into the relationships with your clients and how you collaborate on a daily basis. If the customer cannot commit to extensive involvement and does not expect major changes in the scope, knowing exactly what they want, Waterfall might be a better option for you. If the customer is available frequently through the duration of the project and the product is intended for an industry with constantly changing standards, Scrum is a great alternative.
What is Scrum?
Now, let's get right to it. Scrum has been the most widely practiced and common agile method used by organizations undergoing agile transformation. To get started with Scrum, we recommend that you begin with a single dedicated team on a fairly simple and short project. It's not hard, and there's not much to do in terms of process, but this is just to get you into the right mindset. If you're completely new to Scrum, or just want a refresher, here's an overview of Agile with Scrum.
Get started by following these steps
1. Define your first Scrum Team
The team is comprised of of 5-9 members. These members all have a combination of competencies and can include developers, testers, support, designers, business analysis, etc. All the members continuously work closely together. The team itself is in charge of delivering shippable product increments by the end of each sprint.
2. Define your Sprint length
A sprint is a time-box that lasts between 7 and 30 days, and typically it remains the same length for the duration of a project. A sprint planning meeting proceeds each sprint where the work for the sprint is planned, and the team commits to completing this work. At the end of a sprint a review/meeting with a demonstration of the completed work is held. Here the improvements are reviewed and work for the next sprint is planned. If you don't have a clue of how long the time-box should be start with 2 weeks. Download our ebook to get a full perspective on sprint planning and avoid rookie mistakes:
3. Appoint a Scrum Master
The Scrum Master is the catalyst of the scrum group. They ensure that the scrum group is effective and progressive. In the event of any impediment, the Scrum Master follows up plus resolves the issues for the group.
You can think of this as the Project Manager for the team, except the person shouldn't dictate what the team works on and shouldn't overly try to micro-manage anything. The Scrum Master will assist the team in planning the work for the coming sprints.
4. Appoint the Product Owner
The Product Owner should be a person that can be in charge of making sure the team produces value from the project to the business, client or whoever wants the project (the end buyer). The Product Owner typically writes the client-centric requirements in the form of stories, prioritizes them, and provides them to the backlog.
A typical product backlog to the left, and sprints to the right. At Forecast you can group by people and ensure every team member is fully utilized.
5. Create the Initial Product Backlog
The Product backlog is a wish list of all of the user stories (requirements) that is expected to be completed in the project. The most important story should be in the top of the list, so the entire backlog is continuously ranked in order based on story importance.
A backlog will typically contain 2 types of work items:
- Epics - High level stories that are very roughly sketched out without much detail.
- Stories - More detailed requirements for what should be done (be possible to do). An epic can typically be broken down into several stories.
A story will typically again be broken down into discrete tasks that the team can work and report time on. A story can in many cases have a type, such as development, bug/defect, chore, etc. New stories can be written and added to the product backlog at any time and by anyone.
As you go further down the backlog the items will typically be more rough with less details. As a story/epic rises in priority more details should be put on it so the team can start working on it.
The Product Owner is free to re-prioritize the backlog as she sees fit, at any point in time.
User stories examples
- As a power user, I can specify files or folders to backup based on file size, date created and date modified.
- As a new user I want to create an account so that I can use Forecast.
- As a book shopper, I can read reviews of a selected book to help me decide whether to buy it.
- A bank customer can change his PIN.
6. Plan and Start your First Sprint
Based on the backlog prioritization, the team now picks items from the list (typically from the top). The team brainstorms and decides on what and how much they can complete in the upcoming sprint. This is called the sprint planning meeting.
Once the team agrees, the sprint is started and the team starts working on the stories. Check out this article to plan your first perfect sprint as much as it's possible.
7. Close the Current and Start the Next Sprint
When the end of the time-box is reached, the end of the current sprint, all planned work should hopefully be done. If this is not the case it's up to the team to decide if the remaining work should transfer to the next sprint or be put back into the backlog.
The team now does a retrospective where they discuss what went well and what could be improved for the next sprint. After that, the sprint planning meeting for the next sprint starts and the process is repeated.
There's no limit for the amount of sprints, except if they are set by a deadline (based on budget or time), or the entire backlog is completed. If none of these criteria are met, the sprints just keep going indefinitely.
Continue reading: 9 Metrics to Measure the Health of Your Sprints.
WARNING! Even though Scrum is simple to understand, it is difficult to master. Some people on the team will love it and some people will hate it. This is perfectly normal and you should encourage people on the team to give it a proper try before they give up. If an individual ends up giving up, then remove them from the team and let another one step in. This also means that the person that is taken off the team no longer should work on the project.
Remember that Scrum projects tend to be hard to predict, from timelines to budgets. Without a concrete plan and complete requirement set, everything remains a bit vague. So much so that agile projects can easily go off the rails when project managers are unsure about the outcomes they want to achieve.
Conclusion
Scrum is a great solution to support rapid project progress of almost any type of project. It is extremely effective in creating agility for any organization, but there are also other methods out there.
If you don't feel like Scrum is the best match for your team and projects, we have a comprehensive guide on this and other methodologies here. Remember, no method is de facto the best - it all depends on your situation.
