Are you ready to get started with Scrum? Here's a guide to implementing Agile with Scrum.
Let's get right to it. To get started with Scrum, we recommend that you start with a single 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.
WARNING! 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.
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.
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 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.
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.
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 backlog to the left, and sprints to the right.
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:
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.
An example of a user story card
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.
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.
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, Agile vs. Waterfall. Remember, no method is de facto the best - it all depends on your situation.
The screenshots from this article are all from Forecast; if they caught your eye, you can get a demo and book a personal meeting with us right here. Forecast is made from the ground up to fit any project, running both Agile and Waterfall methods.