Someone stops you in the hallway and tells you, “Hey, we need you to fill in on team so-and-so.” Excited by the prospect of supporting a new application and possibly new technologies, you head to the conference room to meet your new teammates. It’s not long into the meeting that you realize something’s off. Why are there Post-Its everywhere? What is that report the PM keeps pointing at? What’s with the timer? And that’s when you realize… you’ve been Scrummed. Since the rise of the Agile Manifesto, Scrum methodology has become an increasingly popular approach in software development. Segue has employed Scrum practices in several projects in the past year, such as ProcureLinx and Lost Dog Café. If you haven’t already, it’s only a matter of time before you get thrown into a Scrum project-but don’t panic yet. Getting thrown into an Agile Scrum software development project doesn’t have to be painful, provided you learn a little bit of the lingo. Here are a few pointers to help you survive your first foray into the Scrum arena.
Agile Activities
Daily Scrum – The meeting you just walked into in the above scenario is probably the Daily Scrum Meeting. Each day all project team members gather to synchronize their work. This meeting should be no more than fifteen minutes, hence the timer that’s sitting on the desk. At this time, team members share (1) what they did the previous day, (2) what they plan to accomplish today, and (3) what possible blockers they see to getting their job done. Sometimes these meetings are standups, as in everyone literally remains standing throughout the meeting. Standing helps remind the more verbose teammates to keep their input short, sweet, and to the point.
Sprint – Instead of cycling, you’re now sprinting… sort of. Instead of having build/release cycles as other project frameworks, you now have Sprints. Scrum project Sprints are set timeframes 1 to 4 weeks long. Each Sprint will have a predetermined list of features that must be accomplished to deliver a new piece of functionality to the customer.
Sprint Review – During a Review the team demonstrates the functionality completed during the Sprint. Like in a build/release walkthrough, attendees will review the newly implemented functionality, and offer feedback that may result in tweaks or new items to work on in the next Sprint.
Sprint Retrospective – This occurs at the end of each Sprint. At this time team members discuss what practices are working well by answering 1. what they should continue doing, 2. what they should stop doing, and 3. what they should start doing in future Sprints. This meeting is usually subjected to the timer as well, but it’s blocked off to last an hour or less.
Agile Roles
Scrum Master (SM) – Your PM is now an SM whose job is to act as a coach to the team. The Scrum Master participates in all the activities, guides the team, deals with any impediments (such as blockers brought up during the Daily Scrum), and aids the team in understanding Agile practices.
Product Owner – Typically the Lead Business/Requirements Analyst in other projects will be the Product Owner in Scrum. The PO represents the interests of the customer and users. They are responsible for maintaining the Product Backlog, prioritizing features, and guiding the team toward building the right product.
Team – A Scrum Team has five to nine members and will include software developers, analysts, testers, designers, and any other roles pertinent to the project. The Team is expected to collaborate and work together to deliver the features to deploy whatever functionality has been committed to in the Sprint.
Agile Artifacts
Product Backlog –(sometimes called a parking lot, wish list, or to-do list in non-Agile projects) The collection of requirements typically in User Story form. In Agile fashion, these User Stories start out short and simple, but are fine-tuned with additional details as part of managing the Backlog. The Product Backlog will grow and evolve throughout the project as more is learned about the product and client’s requirements change.
User Stories – a non-technical format that describes a feature in context of a given type of user and specifies the acceptance criteria for determining when the feature has been successfully delivered. Focusing on individual user needs helps the team to understand why a feature is important to a given user, and also ensures that each feature provides value to a user upon delivery. The team also provides high-level estimates for each backlog feature, allowing the product owner and client to re-prioritize based on the level of effort.
A Sprint Backlog – For the most part, a Sprint Backlog is similar to a Product Backlog, except that it contains only the features that are being tackled in a particular Sprint. Features not completed in one Sprint may rollover into the next Sprint, or can be pushed back into the Product Backlog to deal with in a later Sprint.
A Sprint Burndown Graph – A graphic representation of the amount of remaining work in the Sprint. It gives the team a quick visual check on whether or not they are on schedule to complete the planned work within the Sprint timeframe.
With the rise in frequency of Agile software development practices, it’s only a matter of time before you get Scrummed. Now that you have some of the Scrum lingo down, it shouldn’t be an earthshattering transition. This is by no means a comprehensive summary of Scrum practices, but it’s enough to help you survive until you can get some Scrum 101 training.