projects.addama.net

Scrum Primer

A lot has been said and written about Scrum. You can, and should, read about it in more depth elsewhere, particularly the The Scrum Guide 2017. There are a lot of specific details that I'll not mention here because that's not the point of this document. This primer is here as an introduction to Scrum in as simple and relatable way I can muster.

That being said, while I am essentially just rephrasing what's in the Scrum Guide, this is all through my own interpretation as Scrum Master, and your experience with Scrum may differ. That's fine; let's meld them together.

Table of Contents

What is Scrum?

Flowchart of Scrum Meetings inside a Sprint, scrum.org

Scrum is an Agile framework; that is, it takes the vague and lofty statements of the Agile Manifesto, and creates a concrete process through which we can live those statements.

Scrum relies on steady and frequent iteration, in the form of Sprints, to progressively add new features and fixes to a product. Sprints last between one and four weeks, and always end with a stable and releasable version of the product.

Scrum aims to be simple and easy to learn, while still providing the very basic elements required for it to be a process at all. This is in keeping with the Agile value of Individuals and interactions over processes and tools.

Scrum has three roles and four meetings. Nothing else we do is considered Scrum if it is not those three roles and four meetings. Your title, your seniority in the company, your weekly meeting, your documents - these are not Scrum.

Roles

Development Team

The Development Team does the work. Anyone responsible for work during the Sprint is Development Team. That includes QA, coders, designers, database engineers, backend greasemonkies, hardware manufacturers, etc. If your work is required to complete the Sprint, you are Development Team.

The Development Team is self-organizing. This means that if you need someone or a specific set of skills, you are empowered to add that person or skillset to the team. It means that the Development Team makes its own sovoreign decisions for how to execute the work, and how that work is distributed across the team. The Scrum Guide says it best:

No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality

Inside the Development Team, there are no officially recognized "leaders" or "seniors" or sub-teams. You are all one team. You are all leaders when your strength and skills puts you in front, and you are all responsible for the outcome of the Sprint.

Product Owner

The Product Owner knows everything about the product. They interpret the needs/demands/whining of the client and the boardmembers into Product Backlog items, which are user stories expressing those needs in explicit and efficient statements. They decide what goes into the product, when, and how important those features and fixes are.

A large part of the Product Owner role is maintaining the Product Backlog. Their ability and skill in this is an ever evolving capability that the Product Owner develops as they work with a Development Team:

To do this, they rely on iteration and feedback from the team, as well as direct help from the Scrum Master and Development Team to refine their user stories. Refining the Product Backlog is a team effort, even if the Product Owner is ultimately the one responsible for its contents and ordering. The highest priority, most likely to be next implemented Product Backlog items should be refined first and to a greater degree, with less important and later scheduled items only refined as time permits.

For the Product Owner to succeed, the entire organization must respect his or her decisions. The Product Owner's decisions are visible in the content and ordering of the Product Backlog. No one can force the Development Team to work from a different set of requirements.

Scrum Master

The Scrum Master knows everything about Scrum, and teaches/evangelizes Scrum to the team, the company, and even to the client if necessary. This is really only half of the job - the Scrum Master's primary function, in my estimation, is to remove roadblocks.

A Scrum Master operates by seeing the process, the people, and the product from above, and identifying things and interactions that are hindering progress and understanding; those things are then remedied with immediate and extreme prejudice. Right there, on the spot if possible. If someone doesn't understand literally anything, the Scrum Master helps them to understand, or points them to someone or some resource that will help. If a meeting is going too long, or is proving unhelpful, the Scrum Master swoops in and tells them to break it up or describes how to make the meeting useful. If some facet of Scrum is inefficient or not quite right, the Scrum Master changes it. Right then and there.

As a servant leader, the Scrum Master works at the beck and call of the Development Team and Product Owner, providing guidance, parental firmness, reassuring hugs, and a rock-solid, ever-present landmark of knowledge and wisdom.

I can't express the full scope of Scrum Master duties better than the Scrum Guide:

Scrum Master Service to the Product Owner

The Scrum Master serves the Product Owner in several ways, including:

Scrum Master Service to the Development Team

The Scrum Master serves the Development Team in several ways, including:

Scrum Master Service to the Organization

The Scrum Master serves the organization in several ways, including:

The Sprint

The Sprint is the beating heart of Scrum, and the container, as well as the enabler, for everything else we do.

The point of the Sprint is for the Development Team to deliver a "done" (more on that later) iteration of the product, implementing Product Backlog items that the Product Owner wants completed. After the Sprint, the Product Owner should be able to immediately, if they want, call all our clients and say we have a new version, new feature, etc, to install. During a Sprint, all work is toward a Sprint Goal, if one has been created, and that work encompasses everything that needs to be done; this includes testing!

Sprints are mini-projects no longer than one month long, based on a Sprint Backlog (a subset of the Product Backlog) that is created during the Sprint Planning meeting. Generally, a Sprint should represent a singular feature, suite of related features, or entire self-contained parts; this is not a hard-and-fast rule, however, as work is not often so easily boxed. While the Development Team is working, the Product Owner remains on-hand to clarify Product Backlog items, and to renegotiate the Sprint Backlog if the selected work proved to be too much or too little.

It's up to the Development Team to jam as much work as it thinks it can do in the Sprint timebox - over time, this understanding of how much work the team can accomplish will be better understood, so don't fret if Sprints sometimes feel overburdened or too light. That is a part of the process, especially for a new team.

Definition of "done"

The Scrum Guide has a pretty big section dedicated to what done means. What could it possibly mean, for any given Scrum Team, to be "done" with a Sprint?

For us, I imagine our definition of "done" is as simple as saying `yes` to these three questions:

For other organizations, however, that can get much fuzzier, much more involved. The thing to take away is that, while we can most likely just have a very simple, obvious definition of "done", we have the option to decide as a Scrum Team on a new definition. If "done" should include some form of external validation (security, HIPAA, etc), then we may need to consider that. If testing should no longer be a part of the Sprint, then our "done" needs to be reevaluated.

The important thing is that this definition of "done" is known to all, universally agreed upon, and is easy to determine a yes or a no at any point in time.

Meetings

Flowchart of Scrum Meetings inside a Sprint

Scrum meetings (also called "ceremonies" by corporate weirdos) are the glue that holds the Sprint(s) together. They are all "timeboxed", which means that they have a mandatory time limit for how long they can take, but no minimum amount of time. The Scrum Master will throw you out if you go too long!

The flow goes like this, in a never-ending circle until the Product Backlog is empty:

  1. The Scrum Team holds a Sprint Planning meeting
  2. The Development Team holds Daily Scrum meetings while they do their work
  3. Once the Sprint Backlog has been completed, the Scrum Team holds a Sprint Review
  4. Whether the Sprint was successful or not, the Scrum Team holds a Sprint Retrospective meeting

Sprint Planning

The work to be performed in the Sprint is planned at the Sprint Planning. This plan is created by the collaborative work of the entire Scrum Team.

I mean... you can't get any more explicit than that.

During the Sprint Planning meeting, the Product Owner presents the features, fixes, and other Product Backlog items they would like to be included in the Sprint. The Development Team then forecasts how much of that it can accomplish in the upcoming Sprint, with an eye toward creating a releasable, useable, "done" iteration. This forecasting can be done in many ways, from assigning arbitrary "points" to each task representing relative difficulty, or playing Planning Poker.

The tasks that the Development Team thinks it can complete are then compiled into a Sprint Backlog, which will be burned down as the Sprint progresses, and represents a contract, if you will, between the Product Owner and the Development Team.

If the purpose of the Sprint is a singular feature or application, a Sprint Goal should be created. This is an efficient, explicit statement of the purpose of the Sprint that can help guide the Development Team in their decisions. For example, a Sprint Goal might be:

Implement user authentication such that any of our clients, regardless of their authentication method, can immediately benefit from added security

With the Sprint Backlog in hand, the Development Team then decides how the work will be accomplished. This involves asking questions like:

Daily Scrum

The Daily Scrum is held by the Development Team, solely for the benefit of the Development Team. This meeting is optionally proctored by the Scrum Master if the Development Team isn't finding the meeting useful, is having too much conflict during the meeting, or is having trouble keeping it within the 15 minute timebox.

During the Daily Scrum, the Development Team reflects on what work has already been done, brings up good and bad things that need light, and plans what will happen for the next 24 hours. This is where you speak up if you need help, or if you noticed someone going above and beyond.

The Development Team can invite anyone else to the meeting if they feel it will be necessary - for example, they may want the Product Owner to sit in on a meeting to ask for clarification on some of the Sprint Backlog items, or to negotiate the Sprint Backlog if there is too much/too little work.

The Development Team can splinter off into its own meetings between members as it deems necessary if more needs to be talked about that won't fit inside the 15 minute timebox.

Sprint Review

During the Sprint Review, the Development Team demos their increment to the rest of the Scrum Team. The Product Owner and the Development Team then agree on what tasks are "done", and what Product Backlog items need to be forwarded to the next Sprint. Any Product Backlog items that are deemed "done" are removed from the Product Backlog, and the world feels a little bit lighter.

Based on this info, the Product Owner discusses the status of the Product Backlog, outlining any changes to it that have happened during the Sprint, as well as what they want to happen in future Sprints. This can include any new clients we signed, and what weird new things they might want, etc.

Overall, the point of the Sprint Review is to bring everyone back together at the end of the Sprint, acknowledge the work that was done, adjust the Product Backlog, and do some pre-planning for future Sprints. It can also serve as a demo to show off new functionality to boardmembers, clients, and other stakeholders.

Oh, and one more thing: the Sprint Review is an informal meeting! This isn't the Development Team standing in front of the principal's office door waiting to be judged - it's the entire team evaluating the current state of the product in light of the Sprint being done.

Sprint Retrospective

Arguably the most important meeting of them all (from an Agile perspective), the Sprint Retrospective is where the Scrum Team takes an honest, transparent, brave look at itself, how it works, and creates a plan for how to encourage the good things that happened, while also discouraging the bad things.

The important thing is that the Sprint Retrospective attendees are A) honest and thick-skinned, and B) positive and accepting. There is a tendency to become defensive, especially when something you did is brought up as needing improvement; but remember that this is all toward making a better product, and making everyone's job easier through iteration and constant feedback. Be brave. Be positive.

This is the meeting where if someone did something great, helped you out, or went above and beyond, you give them recognition. This is where you share tools and processes that worked for you so that others can benefit from them. This is where people link up to correct/mitigate their deficiencies, whatever they may be. After each successful Sprint Retrospective, we all have the opportunity to come away better.

Common things that can come up in a Sprint Retrospective:

Reflections From Your Warmaster Scrum Master

There are two primary reasons why I like Scrum over other processes I've been a part of or researched. Firstly, as a developer by trade, I appreciate that one of the core tenets of Scrum is that the Development Team is self-organizing. In non-Scrum terms, that means you have to leave the devs alone and let them make their own decisions. Leave the devs alone! Wow. No other process has that, and I deeply appreciate that this is a thing we can have after so many decades of being leashed to some pointy-haired-boss or another that couldn't possibly understand the complexity and demands of the work.

The second reason I like it is more practical, and it's this: Scrum is simple. It's dead simple. You only need to know a handful of things, and that makes it easy to teach and easy to accept into your life. There's only a handful of meetings, and they are all distinct and necessary. You can only have one of three roles. There isn't a meeting before the meeting, or a meeting to review changes to the documents used by other meetings. There aren't document outcomes from every meeting that need to be created, drafted, reviewed, validated, signed, printed out, stored, distributed, cooked, eaten. Just people, requirements, the Sprint, and the few barebones meetings that join them all together.

Three roles. Four meetings. One person owns and understands all the requirements. One person owns and understands all the meetings and the Scrum process itself. The Dev Team decides how much work it can/should do, how long it will take, and how those tasks are executed. That's it - and that's why I like Scrum.

Build projects around motivated individuals.

Give them the environment and support they need,

and trust them to get the job done.

Resources