Scrum – A Detailed Breakdown

How Scrum is organized..

With Scrum there is a Development team, a Scrum Master, and a Product Owner. Those are the 3 main roles that are involved with Scrum. There is also 3 artifacts that are used to be an effective Scrum Team. The artifacts are, Product Backlog, Sprint Backlog, and Product Increment.

Dev team role:

  • 3-9 people (avoiding cliques)
  • Team self-organizes and people can volunteer for certain parts
  • At the end of the sprint you need to be able to SHIP (working software)

Scrum Master role:

  • Coach for the Dev team
  • Facilitator that teaches how to max ROI using Scrum
  • Clears roadblocks for the Dev team
  • Defender of the Dev team

Product Owner role:

  • Single person representing the stakeholders and customers
  • Communicates what the customers needs are directly to the Dev team
  • Has final authority (and accountability) in managing and owning the product backlog

**Backlog is basically a feature list which helps identify higher priority features that the Dev team should finish first (highest priority goes on top)

Self-Organizing:

  • Within a certain boundary the Dev team has autonomy
  • Requires trust, and trust is built over multiple sprints

**Product Owner presents the problem a customer needs solved and the Dev team self-organizes to figure out how to accomplish the end goal. This in direct contrast with an older model which dictated each individual task to specific developers.

Scrum Artifacts (What you need to be effective with Scrum)..

Product backlog, what all do we need to complete the product?

    • The process of creating a Product backlog is kicked off by the Product Owner
    • This is the phase where the entire team, Product Owner, Scrum Master, and Dev team get together to figure out what will be required to complete what the customer is asking for.

Sprint backlog, what can we accomplish within the sprint?

    • Feature list you decided to work on, subset of items from the Product Backlog
    • The Sprint backlog can be adjusted while sprinting if something has a dependency

Product Increment, is the sum of all the Product backlog items completed during a Sprint and the value of the increments of all previous Sprints.

    • The entire goal of these Sprints is to get out WORKING software
    • New organizations will struggle with this until they have multiple Sprints under their belt

**The state of the backlogs can be looked at later on using an array of different charts that will help show whether or not you’re hitting deadlines, and how many backlog items are being completed on a daily/weekly basis, for example.

**The primary focus of the entire process is putting out working software by the end of the Sprint. One of the key reasons for this 1-4 week Sprint model is to use the working software you finished to get feedback from the customers quickly, rather than making the entire product then being told, “that’s not what we asked for”.

Charts..

Charts used to check how effective the previous or current Sprint is:

BurnDown – A BurnDown chart helps visually show the team’s progress as tasks are being completed

    • Ideal Tasks Remaining – what you hope to get done during the Sprint
    • Actual Tasks Remaining – what you have actually gotten done during the Sprint

Extra..

Brand new Sprint teams:

  • May not have any working software to release (normal not worth freaking out about).
    • This would result in a lot of “in progress tasks” and all of this will be examined in the Review stage of the Scrum model (which you will read about below). During the review, the team will decide whether or not they need to pivot or finish the “in progress tasks”.

Customers/Stakeholders:

  • Want working software, and this is the goal by the end of every Sprint.

Dev team:

  • Wants feedback from the customer, good or bad.
  • Some customers, may not be familiar with this style of approach and may not know to give criticism. Rather they will just clap and that is not beneficial.

An Event Board:

  • Having an event board, where you can visually see tasks getting done, is a great motivator for the Dev team
  • If you have seen HBO’s Silicon Valley, they used this same method.

Scrum events (1-4 weeks, mostly 2 week sprints, keep the sprints consistent)..

Sprint Planning, is a working session to discuss the work and effort necessary needed to meet their sprint commitment.

    • Two parts:
      • What can we do in the sprint
      • How will we accomplish the work we decided on

Daily Scrum, is a daily meeting.

    • Less than 15 minutes, and you’re usually standing the entire time (another reason it’s only 15 minutes)
      • What have you done?
      • What are you going to be doing?
      • Do you need help?

**The daily scrum is an event for the Dev team, and if no one has anything to say then spending exactly 15 minutes is not required. The entire point of a daily scrum is to quickly find out where everyone is.

Sprint Review, you want feedback, good or bad.

    • End of sprint (get together with stakeholders/customers)
    • Look at the product backlog (does it still make sense?)
    • Does the customer still want what you made or do you need to make changes?
    • Product Owner/Scrum Master will give the Dev team an idea for the budget and market climate while the Dev team has been sprinting
    • Collaborate on what to do next (customer -> Dev team)

Retrospective or review, leads to better behavior and improved work spirit.

    • The heart of continuous improvement
      • Inspect the people, process, relationships, tools
      • Save some time to talk about what worked (Celebrations are good!)
      • Celebrate what we built, what worked, and the good parts of our release

Final notes, Scrum does NOT solve problems.  It exposes them. You can then use that information to rough tune and become a more effective team. Scrum is a great tool that appears to be the direction most organizations are going. Therefore, it might not be the worst idea to become more familiar with the inner workings of Scrum.

Fun Fact, the creators of scrum named it scrum because of rugby.

Here is the rugby definition: Scrum is an ordered formation of players, used to restart play, in which the forwards of a team form up with arms interlocked and heads down, and push forward against a similar group from the opposing side. The ball is thrown into the scrum and the players try to gain possession of it by kicking it backward toward their own side.