Scrum is a lightweight framework designed to help small, close-knit teams of people develop complex products.

Of course, Scrum isn’t just applicable to software projects as you can use it to build a better mousetrap or really anything for that matter. I’ve seen it used in every single part of an organization, even legal and finance.


Typically, a Scrum Team is about 7 folks, plus or minus 2. So, the most that you’d have is 9 and the smaller teams have about 5 team members. This, of course, doesn’t really work for early-stage startups where the founding team might be just 2 or 3 folks. Heck, it might just be you.

There are 3 roles:

  1. Product Owner
  2. Scrum Master
  3. Team Member

The Product Owner represents the business and handles the relationship between the product and the investment of time, resources, and energy that the business is incurring. The PO ensure that maximum ROI is achieved.

Tactically, they help the team understand what is higher priority and what is lower priority, what might be more valuable to work on and less valuable to work on. Their role is to help shift resources and time and attention. Sometimes, but not always, they may prioritize things on the backlog but they are the only ones who can ask the team to work and who can change the order of the backlog.

Finally, they help the team understand the requirements so as to maximize time and resources to produce higher efficiency and effectiveness (thus boosting ROI). They do this by creating user stories that generally look like this:

As a <type of user>, I want to <do something>, so that <some value is created>.

A Product Owner:

  • Holds and maintains vision for the product
  • Represents the interests of the business
  • Represents the customer(s)
  • Owns the backlog
  • Orders and priorities the product backlog
  • Creates acceptance criteria for the items in backlog
  • Is available to assist and answer team’s questions

The Scrum Master plays the role of coach and helps guide the team to better self-organization, performance, and decision making. While the team focuses on building the best product, the SM focuses on building a high-performance team.

Good SMs are one part coach, one part champion, one part guardian, one part facilitator, and, of course, an expert at Scrum mechanics. They equally champion the product, the team, and the individuals on the team.

They are not anyone’s boss, mind you, but rather a peer, on the team with a very distinct role. In summary, they:

  • The resident Scrum expert and advisor
  • A coach for the team
  • The remove blockers, impediments, and help the team continue to move forward
  • The facilitate the backlog and the other parts of Scrum

A Team Member has the most authority in the Scrum system as they are part of a self-organized body of folks who are committed to building kickass products. They have the authority to decide how the work gets done, what tools they should use, what techniques should be deployed, and the associated costs of those decisions.

The prevailing wisdom is that people who do the work are also the best authority on how to best said work.

A fully functional Scrum team should have all of the relevant skills necessary to build the product which means that most, if not all, of the team members are specialists in their own right. But this doesn’t mean that they silo their effort as the uniform goal is to deliver a working product to the business and customer. This means that team members will often times work in other areas that may be outside of their speciality to get the job done.

High-performance teams share the load, always.

Team Members:

  • Responsible for completing user stories to incrementally increase the value of the product
  • Self-organize to get all of the work done
  • Owns and creates the estimates for the work
  • Owns the “how to do the work” decisions
  • Avoids single-minded, specialist-thinking and instead considers the team’s performance in aggregate above their own

Scrum Artifacts are essentially the tools that practitioners of Scrum use to make great products and to increase visibility and communication effectiveness.

The Product Backlog is the master list of all of the planned and desired deliverables for the product. This can (and should) include features, bugs, documentation, Q/A, and more, essentially including anything that is meaningful and important to create for the product as a whole.

Some call items within the backlog just “backlog items” while other teams might call them user stories. This is preferential and the team can decide what specific terms they want to use.

The list of backlog items or user stories is prioritized and ordered from the most important to the least important. The items at the top are also specific, well understood, and can be executed against quickly and efficiently. This means that they are also generally small tasks. Items further down the list are more ambiguous, less defined, and larger in scope and scale.

Each item in the backlog should generally have the following:

  • Which users the story will benefit (who is it for)
  • A brief description of the desired functionality (what needs to be built)
  • The reason that this story is valuable (why we should do it)
  • An estimate as to how much work the story requires to implement
  • Acceptance criteria that will help the team know when it has been implemented correctly

The Sprint Backlog is the team’s to do list for the sprint. Unlike The Product Backlog, it has a finite life-span: The length of the agreed upon sprint. It includes all the stories that the team has committed to delivering in the sprint and the associated tasks. Stories are deliverables and can be thought of as units of value.

Burn Charts help the team understand the relationship between time and scope. Points are on the y-axis while sprints are on the x-axis. As time progresses, one can see how many points are remaining in the overall product and the relative speed and pace at which the team is working through the points and the sprints. A Burn Down chart shows what is left to do while a Burn Up chart shows how much scope the team has got done over a select period of time.

When more items are added to the backlog one can see the number of points increase through a vertical line up and when things are removed it’s a vertical line down.


The Task Board represents all the team’s tasks visibly so that everyone knows what is being worked on and by whom. The more simple of task boards have three columns:

  • To Do
  • Doing
  • Done

Tasks are simply moved from left to right as they are worked on and progress is made. The Task Board is a visible reminder of the team dynamics and mechanics in play: We are all in this together and we sink or swim as a team. It allows the team to inspect the work and then adapt as necessary. Other stakeholders can also see the progress and provide value as well.

How the team defines “Done” is also very important because it will be different for different teams. Also, if it is not clearly defined then it will create confusion among different team members and stakeholders as they will have their own interpretation as to what “done” really means.

For instance, a software developer might consider “done” when they have finished writing their code while a business person may consider the task “done” when it is ready to sell to customers. Clearly, these are two very different interpretations of “done”!

Effective Scrum Teams define what “done” means and then apply it to their Task Board and user stories. This is what is often described as the “Definition of Done” and may be singular in nature or a combination of elements. Printing the definition out and putting it alongside the Task Board is an often used tactic as well so as to remind the team what it really means.


The Sprint Cycle consists of several meetings, often called “ceremonies”:

  • Sprint Planning
  • Daily Scrum
  • Story Time
  • Sprint Review
  • Retrospective

The Sprint Cycle (or “Sprint” or “Iteration”) is how you get work done: A fixed period of time where you work on small parts of the larger product. The goal after each sprint is the same: A demonstrable working piece of software.

The more effectively a team completes their sprints the faster the product is built and the faster the business realizes a high return on investment. The team will decide, after each sprint, whether the product is shippable (i.e. can be sold to customers).

In general, the shorter the sprint cycle is the faster they can get feedback which helps make subsequent sprints even more effective. This cumulative effect is not to be taken lightly, by the team or the larger business.

It is very common for teams to have sprint cycles that last 2 weeks, although in early-stage ventures the cycle times might be as small as 1 week. When Scrum was first introduced the cycles were around 4 weeks or one month.


For a one week sprint, you’ll usually have the following with time breakdowns:

  • Monday: Sprint Planning (1–2 hours)
  • Tuesday: Daily Standup (15 minutes)
  • Wednesday: Daily Standup (15 minutes), Story Time (1 hour)
  • Thursday: Daily Standup (15 minutes)
  • Friday: Daily Standup (15 minutes), Sprint Review (30 minutes), Retrospective (1–2 hours)

For Sprint Planning the goal is for the team to commit to a set of deliverables for the sprint and to also identify the tasks required to deliver upon the agreed user stories or backlog items. With the team, the Product Owner presents the suggested stories to prioritize and the team discusses, sometimes vigorously, their position and priority.


It’s worth noting the delineation of role and responsibility and authority between the PO and the TM: The Product Owner decides which stories are going to be considered for the sprint while the team members doing the work are the ones who decide how much work they can reasonably take on.

In the second part of the meeting the team then decides how the work will be done, decomposing the agreed stories into tasks. As tasks are defined the resulting stories on the backlog may change as well as more information become apparent and usable. It is not uncommon for a team to over-commit to the number of user stories in the beginning and then have to remove some as more details emerge.

The result of this planning session is the Sprint Backlog which consists of the aforementioned user stories and the resulting associated tasks. The Product Owner can give more user stories if the team requests them or has room but should be wary of overcommitting the team.

The Daily Scrum, or Daily Standup, is when most teams hold a quick meeting near the beginning of the day to share the following:

  • What tasks have been completed since the last Daily Scrum
  • What tasks are to be completed by the next Daily Scrum
  • What obstacles are slowing the team down

Each member of the team participates and the meeting should be pointed, specific, and brief. The point is for everyone to get an idea of global progress and to identify issues before they become larger ones. This allows the team to actively inspect and adapt to changes in near real-time. Surfacing issues is the goal but creating solutions during the Daily Scrum is not.

Story Time happens mid-week or mid-Sprint to discuss how the team can improve on the stories in the product backlog which are user stories for future sprints. These are not user stories in the current sprint.

The Product Owner defines and refines the acceptance criteria for user stories in the backlog and also point values for stories that do not yet have an estimate. This is essentially an opportunity for the team to guess at how much work will be required to get the story done.

Not all Scrum Teams have an official Story Time and many teams do this at-will daily. It just depends on the size of the team and their internal culture of decision making.

The Sprint Review is a public declaration that the current sprint or cycle is done and it’s time to show the work that’s been completed. Stakeholders from the business are often invited to review progress as well.

It is often the case that not all of the user stories were completed so the audience should be obviously made aware of those details before presenting. The stakeholders, upon review, will undoubtedly have feedback and suggestions and it is the job of the PO primarily to capture these things for review later.

No decisions should be made during the review as those are already done in Sprint Planning.

The Retrospective is the final meeting for the team to gather so that they can inspect, adapt, and optimize their ever-improving performance as a team. Unlike the Sprint Review which included outside stakeholders in addition to the Scrum Team, this meeting is just for the team itself.

The conversations should revolve around what they learned during the sprint and how that learning can be effectively applied to the next sprint so that work can be done more efficiently and more effectively. And, unlike larger “post-mortems,” the idea here is to focus on just a handful of larger strategic changes instead of creating a master list of all of the things that went well or that went poorly.

Inspect and Adapt all the things! The goal of short sprints or cycles is so that continuous improvement happens faster and that any important learnings aren’t lost into the ether. The Scrum process is designed specifically to catch these new and important learnings and then apply them immediately into the system for improvement.

Finally, it’s worth noting that the Agile Manifesto’s values and principles are not directly part of the Scrum Framework but were definitely used to inform the Scrum Process as a whole. It’s worth reviewing them here.

Random backstory: I actually wrote this out for a much older startup… 6 years ago! It sat in my drafts for that long.

I finally got around to looking through it and publishing it. I suppose this does prove, to a small degree, the utility of this type of framework or system across multiple projects — it’s relatively timeless! Hopefully it’s useful for you too!

About me: I’m currently leading Product & Engineering at YEN, a Meta Cryptocurrency Exchange and Social Platform, where we’re still applying these ideas liberally.