How to Get Started With the Agile Scrum Methodology

So you want to use Agile Scrum methodology, but are not sure how to get started? Below is a high-level guide with some quick and dirty definitions to inform you as you start to transition your team.

Getting Started With Scrum Methodologies

Let’s start with the Agile Manifesto which emphasizes:

• Individuals and Interactions over Processes and Tools
• Working Software over Comprehensive Documentation
• Customer Collaboration over Contract Negotiation
• Responding to Change over Following a Plan

While the items on the right are important, the items on the left are more important.

Now, Identify the Team:

• Stakeholders: These are the people who have the wants and needs and are the reason the team forms to develop the software. Stakeholders collaborate with the Product Owner to develop the stories.
• Product Owner: Represents the stakeholders’ interests, and has a solid understanding of users, the marketplace, competition, and type of system being developed.
• Scrum Master: The servant leader that does everything possible to help the team perform at their highest level.
• Development Team: A self-organizing group dedicated to delivering a potentially releasable increment of product at the end of each sprint.

Once you know who is involved, it’s time to get started!

Project Initiation (Sprint 0)

Sprint 0 is not a Scrum principle. As such, it has caused some controversy and can be polarizing among Agile enthusiasts. DO NOT use Sprint 0 to fall back into waterfall practices by using it to design the application and gather all requirements. That said, it has been used successfully to:

• Set up an initial architecture (development, quality assurance, test environments) so that the team can hit the ground developing on day 1 of sprint 1
• Identify initial product backlog, so there is a robust backlog to prioritize for sprint 1
• Schedule required ceremonies
• Prepare preliminary design that can be used as a foundation for the first stories, but that can be refactored and added to as the project progresses

Whether you do these things in a Sprint 0 or simply prior to getting started, here are some tips to set yourself up for success:

Choose Your Tools

Select collaboration tools to be used by and for the team. Pick tools to match your process and not the other way around. I’ve had success with Scrum boards, Jira, Wrike, and Cardboard.

Facilitate a Project Initiation Meeting

Complete a Project Charter with the team’s involvement, including:

• Define definition of done: What will the team need to have accomplished for the story to exit the sprint? This ensures when each person says they are ‘done’ it means the same thing.
• Define team agreement: What rules will the team follow to hold themselves accountable? This is part of the team self-organizing and acknowledging what they need to be successful.

Plan Sprint Ceremonies

• Initial backlog grooming (story mapping): One time only at start of project/Sprint 0
• Sprint planning: Recurring 1^st day of each sprint, time box for 1 hour per week of the sprint (2 hours for typical 2-week sprint)
• Daily Scrum/Standup: Recurring daily during sprint, time box for 15 minutes. Add a 16^th minute for additional collaboration, time box for 15 more minutes and dismiss any team members not necessary for discussion
• Backlog grooming: Recurring 3 days before last day of each sprint, time box for 1-6 hours depending on needs/complexity of stories
• Sprint review: Recurring last day of each sprint, time box for 1-2 hours
• Sprint retrospective: Recurring last day of each sprint, time box for 1 hour

Conduct initial backlog grooming sessions

• Create a solid backlog with enough stories for at least 2 sprints if possible
• Prioritize stories
• Development team estimates stories

Start Sprinting

Day 1: Sprint Planning

• Developers commit to stories until you have enough to meet the capacity for the team and based on the priority of the product owner/stakeholders. After the first sprint, the team will use average velocity to guide them on how much to commit to in a given sprint.
• Determine capacity based on the hours available from each team member and subtract the time needed for the ceremonies during the sprint. For example, 4 developers have 40 hours each week which totals 80 hours each for the 2-week sprint, then subtract the daily standups, sprint planning, backlog grooming, sprint review, and sprint retrospective time to determine actual hours to complete stories. Subtract 12 hours for ceremonies from each developer, so their new total availability is 68. Multiply 68 by 4 and the total capacity is 272.

Daily Scrum/Standup and 16^th Minute

• Team meets and relays what they did the day before and what they plan to do. This is a meeting less for status and more for collaboration purposes when there are dependencies and coordination needed to self-assign stories. Remember, no one is telling each team member what to do, they are organizing to ensure all stories are accomplished by sprint end.
• 16^th minute: This is an extra 15 minutes after standup for team members to talk through a challenge or collaborate if needed without the whole team. Only pertinent members on the team will attend this part. It’s not a strict Scrum principal, but widely used and very effective since folks have this time blocked off on the calendar. The biggest trick is to excuse folks from the meeting if they are not necessary for a given conversation.
• Backlog Grooming: 3 days prior to sprint end
• Maintaining a backlog of stories generated by Product Owner
• Prioritizing stories
• Asking questions/clarifying requirements: Developers should ask as many questions as needed to flesh out enough requirements to estimate and complete the story for the Product Owner’s needs
• Estimating stories: Identifying test case scenarios can assist the team in clarifying requirements
• Gives the product owner time to get open questions answered prior to sprint planning

Last Day: Sprint Review and Retrospection

• Review: The team will review/demonstrate stories for product owner to capture immediate feedback and to evaluate the potential impact on future development. They should be prepared with dummy data and examples set up to show the new feature.
• Retrospection: The team will consider the sprint and determine what they want to stop doing, start doing and keep doing. Reflection at the end of each sprint gives them a lot of opportunities to make improvements. A great difference in quality, administration, and practice could occur in only 2-3 sprints (as short as 4-6 weeks).

As much feedback as possible is highly encouraged and vital to the success of the team!

Rinse & Repeat

Continue the process of sprinting until all items in the backlog are complete. Happy Sprinting!