Agile Development: Scrum

4 min read
DevOps - Igniting Your Startup

Scrum turns ambitious individuals into small but powerful team players, speeding development up a notch, and getting the right product before your customers.

Scrum works best for new teams, of 3 to 10 members, but never 8. I don’t know why, but there’s something against having 8 members in a Scrum team. Scrum is a development framework that comes with a few roles, artifacts and events.

Regarding the roles, a typical team can have one Product Owner (this is the Project Manager), one Scrum Master (who moderates meetings, removes impediments from the team’s way) and several Scrum team members. These can be developers, testers, designers, whatever your team needs.

Everything in Scrum is centered around sprints. Sprints are short periods of time (one to four weeks), during which the team has to develop to the stage of a “potentially shippable product”. Meaning it has to work. They have to show you something working. Not promises and pictures, but working software.

Here come the artifacts

Some of the important artefacts in Scrum are:

  • Product Backlog – here is the place where all the Product Owner’s requests (called user stories) go. User stories have a typical format such: “As an accountant, I want to be able to define new products.”
  • Sprint Backlog – after the team agrees to what can be done in a sprint, the items go in the Sprint Backlog. The team can split the user stories into smaller tasks, in order to estimate them. Estimation helps them to know how much they can accomplish in future sprints.
  • Sprint Burndown Chart – this is a nice and simple chart with days on it’s X (horizontal) axis and estimated hours remaining on the Y (vertical axis). After a few days, drawing a line that connects the dots will reveal a trend that points out if the product is behind schedule or ahead.
  • Product Increment – this is the output of the development. The “potentially shippable product”. You wouldn’t want a “product excrement”, now would you?

And then, there are the events

Events in Scrum are several, each important in its own way:

  • Sprint Planning – this is when all the team members, including the Product Owner, gather around to discuss what needs to be implemented. Scrum is not a practice where the Product Owner comes with all the specifications already printed and passed around on flyers, but where he brings the “user stories”, based on which the discussion is supposed to start, breaking down each user story into simple, estimable tasks. Here is also where the team estimates how many “user stories” it can commit to for the following sprint.
  • Daily Standup – Each day, on a specific time, the whole team (and optionally the Product Owner) gathers together, each answering three simple questions:
    1. What I’ve done yesterday?
    2. What I will do today?
    3. What issues I foresee in implementing my tasks.

    This helps the entire team to know who works on what, and it also helps the team member to be more responsible, as they can’t say the same thing each day.

  • Sprint Review (demo) – After the sprint is done (and this is decided by time, not by what has been implemented), there’s a meeting where the team demonstrates what they have been working on in the past sprint. The demo can be for the Product Owner or for the Stakeholders. Since the idea is to make a potentially shippable product, the team can’t come to this meeting saying they’ve spent the entire sprint working on the database. It almost always has to be something “showable”.
  • Sprint Retrospective – After the sprint review, the team – preferably without the Product Owner – gathers around to talk about the process. What went right? What went wrong? What can be improved? And to make this meeting actually productive, a list of actionable items has to be drawn out, with responsible people to sort them out.

So why ‘to SCRUM’ and not ‘to Waterfall’

This whole Sprint methodology brings “working software” in front of potential customers way faster than the traditional “waterfall” method. Ideally, potential customer would see something working after the very first sprint. That’s typically two to four weeks. Not fourteen months, like the waterfall would provide.

And the most important thing is that after they see the product, they can provide valuable feedback, that will help you and your team adjust the product, going further and further towards what customers really want. And it also keeps potential customers in the loop, watching the product as it grows. This builds trust, and long lasting relationships that will prove quite beneficial in the long run.

Interesting read?