The Scoop on Scrum Development

When I got my Certified ScrumMaster license in Silicon Valley a few years ago, I was surprised to find 20 or so employees from Apple—not from their Development team, but from their Marketing team—there to learn about Scrum. Now, that doesn’t seem so strange. Scrum is quickly affecting more and more departments in businesses everywhere, as teams outside of IT are trying to find better ways to deliver the right thing to a customer as efficiently as possible.

If you’ve just embarked upon your first Scrum project, or suspect you might be soon, there are a few basics you’ll need to know.

Scrum is an Agile methodology. By definition, Agile methodologies are fast-moving project approaches with the following qualities:

- Empirical: derived from or guided by experience or experiment
- Iterative: repeat a process with the aim of approaching a desired goal, target or result
- Constantly Evolving: customers/stakeholders are involved throughout the duration of the process and the requirements emerge as you go

This “Agile Manifesto” will give you an idea of what is important in Scrum Development projects:

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

The History of Scrum

The term “Scrum” was first introduced in a 1986 article by Takeuchi and Nonaka, published in the Harvard Business Review. It then resurfaced in 1995 at the Business Object Design and Implementation Workshop, and gained even more traction in 2001 with Ken Schwaber and Mike Beedle’s book, Agile Software Development with Scrum. The Scrum Alliance was founded in 2002.

Today, Scrum is used by huge companies like Adobe, Amazon, Apple, CNN, Facebook, Google, and Microsoft to manage various aspects of their business.

“Sprinting” Through the Basics

Scrum project teams are broken up into cross-functional, self-organized teams, and project requirements are stored in the product “backlog”generally in the form of user stories. The project progresses in 2-4 week iterations of work called “sprints”.

No (or very limited) changes can be made to a team’s Sprint “backlog” during a sprint, which keeps a team focused. The product is designed, coded, and tested during each sprint, resulting in a “potentially shippable” product increment.

Source: Mountain Goat Software

Remember: Scrum is a framework—there are no implied engineering principles or practices. The pieces of this framework are:

1. Roles

- Product Owner: helps the team find its clear, elevating goal by defining the features of the product (with the customers of course), developing and prioritizing the product backlog, making scope/schedule tradeoff decisions, and adjusting priorities as requirements emerge. Responsible for the “what.”

- Scrum Master: a servant-leader that flattens the hierarchy and coaches colleagues to help them improve. He or she protects the team from distractions and helps them become fully functional and productive. Responsible for the “how.”

- Scrum Team: a cross-functional team of developers, testers, user experience experts and business analysts. Typically should be 7 people plus or minus 2.

2. Ceremonies

- Daily Scrum: A 15-minute meeting every day with the entire team. The primary purposes are to unearth anything that may be impeding a team member and to promote communication. Stakeholders may attend as silent observers but must remain silent. Three questions everyone on the team should answer are:

- - - What have you done since yesterday?
    - What are you planning to do today?
  - - Do you have any impediments/stumbling blocks?

- Sprint Review: To promote transparency and give stakeholders a chance to provide feedback, this is held at the end of each sprint. The team gives demos of deliverables, which are accepted or rejected by the Product Owner. This helps prevent the “Big Bang” effect at the end of a project where stakeholders are surprised by a deliverable (positively or negatively).

- Sprint Retrospective: This happens at the end of a sprint, and is a way for the team to take an inward look at what is working and what is not. Teams should focus on areas that will improve cohesiveness and efficiency. Three questions that should be answered are:

- - - Start doing
    - Stop doing
    - Continue Doing

- Sprint Planning: This happens once per sprint at either the beginning or the end. The team commits to a set of user stories, that have been prioritized by the Product Owner, that they believe can accomplished by the team in the sprint. The user stories are broken down into tasks, and the tasks are estimated in hours (whereas the user stories are generally estimated relatively in story points far prior to this meeting). The result? A sprint backlog.

3. Artifacts

- Product Backlog: comprised of user stories and consisting of features, bugs, technical work, and knowledge acquisition, the product backlog is ever-changing and evolving due to stakeholder feedback. The backlog is owned by the Product Owner whom prioritizes it and keeps it clear and concise.

- Sprints: regular, repeatable word cadences. A product release consists of and progresses via a series of sprints. These should not exceed 30 days—the typical length is two weeks.

- Burndown Charts: A way to visually gauge the progress of a team during a sprint.

Source:Team Pulse

When to Use Scrum

Scrum is a simple “inspect and adapt” approach. It can really be applied anywhere and is scalable from small to big projects. Outside of software development, I’ve seen it implemented in Manufacturing, Marketing, Sales, and Engineering.

Alternatives to Scrum (other agile frameworks)

You may have heard of some of these: Kanban, Extreme Programming (XP), Scrumban,Test Driven Development (TDD), Feature Driven Development (FDD), and Lean.

Connect with Todd Miller on LinkedIn

Enterprise Agility

Operational Excellence