You’ve been grinding through tutorials. You've built a portfolio site, maybe deployed a few projects on GitHub. And now you're trying to land a job or join a team.

Then the interviews start.

Suddenly, people ask:

• "Are you familiar with Agile?"

• "Have you worked in a Scrum environment?"

• "What’s your experience with sprints?"

Cue the imposter syndrome. Because no one teaches this stuff in JavaScript 101.

This guide is for you.

I’ll help make the Scrum process – a very common way developers work together – make actual sense. I’ll walk you through the basics, but also tell you what developers actually do, how standups feel when you're new, and what’s expected of you when you’re no longer coding in a vacuum.

Let’s break it down.

Here’s what we’ll cover:

• What Even Is Scrum?

• The Three Roles in Scrum (and Who Does What)

• The Scrum Rhythm: What a Sprint Actually Looks Like

• Who attends the Ceremonies:

• Standups: Where You Talk Like a Human, Not a Robot

• Sprint Planning

• What’s a User Story and Why Does It Sound Like a Children’s Book?

• What Counts as “Done”? Definition of Done and Why It’s Important

• Demos, Retros, and Saying the Hard Things

• Tools You Might Encounter

• If You’re Preparing for a Job, Here’s What You Can Do

• Final Thoughts

What Even Is Scrum?

Scrum is not a tool. It’s not a software. It’s not some elite thing only PMs care about.

It’s a lightweight framework that helps software teams build things incrementally, together, in short focused cycles called sprints.

Scrum is used by everyone from FAANG teams to indie dev shops because it helps:

• Keep teams aligned

• Deliver working software fast

• Course-correct often

• Spot problems early (before they go nuclear)

It’s the opposite of the old-school “build for a year and pray it works” model.

The Three Roles in Scrum (and Who Does What)

Scrum officially defines three roles. Here's what that means in practice:

1. Product Owner (PO)

Think: Vision-holder. They decide what the team builds and why. A product owner:

• Writes user stories (think of these as feature requests written from a user’s point of view)

• Prioritizes the work

• Clarifies what success looks like

• Says “yes” or “not yet” to features

2. Scrum Master (SM)

Think: Air-traffic controller meets therapist. They make sure the process works. The are master Facilitators, like between Dev and PO’s. A Scrum Master:

• Facilitates meetings

• Removes blockers (“Your AWS access is stuck? I’ll escalate it.”)

• Coaches the team on Scrum practices

• Doesn’t manage people – manages flow

3. Developers (YOU!)

Think: Builders. You write code, test it, ship it, fix it, and improve it. You also:

• Break down stories into tasks

• Pick up work from the team board (like Jira or Trello)

• Communicate progress

• Demo what you’ve built at the end of the sprint

You might also work with designers, testers, or DevOps folks – but within Scrum, you’re all “developers” building a product together.

The Scrum Rhythm: What a Sprint Actually Looks Like

Image Source: https://www.invensislearning.com/blog/what-are-scrum-ceremonies/

Understanding the Scrum Cycle

So, what does it actually look like when a team uses Scrum to build software?

Let’s walk through a full sprint – not just the buzzwords, but what really happens when a group of humans tries to plan, build, review, and improve together. Think of this as your backstage pass to the rhythm of modern teamwork.

📦 Step 1: Build and Refine the Product Backlog

Before any coding starts, the team needs to agree on what they might build – not just this week, but in the near future too.

That’s where the Product Backlog comes in. This is a big, running list of everything the product might need – features, bug fixes, improvements, ideas, and maybe a few wild dreams. It’s like the wishlist for the product, but more organized (ideally).

The Product Owner is responsible for maintaining and prioritizing this list. They decide what’s most important to work on based on customer needs, business goals, and feedback.

But the PO doesn’t do this in isolation. Enter the Backlog Refinement meeting.

In these sessions, the Scrum Team – that’s the PO, the Scrum Master (SM), and the Developers – come together to:

• Review the most important upcoming items

• Clarify any vague or confusing parts of each task

• Break big items down into smaller, buildable pieces called user stories

• Estimate effort (how much time or complexity is involved for each story)

This meeting makes sure the team isn’t caught off guard in the sprint – that they understand the work ahead and can actually start sprinting when the time comes.

🧭 Step 2: Sprint Planning – What Are We Building This Time?

Now that we’ve got a solid backlog, it’s time to pick what to build right now.

At the start of each sprint (which typically lasts 1 to 4 weeks), the team holds a Sprint Planning meeting. This meeting sets the stage for the entire sprint – it’s like the huddle before the big game.

In Sprint Planning, the team:

• Reviews the top items from the backlog

• Discusses what can realistically be completed based on their availability and capacity

• Chooses a handful of these stories to commit to

• Defines a Sprint Goal – a simple statement that captures the purpose of this sprint

For example, the Sprint Goal might be:
🎯 “Allow users to reset their passwords.”

Every user story chosen should contribute to that goal. The collection of these stories becomes the Sprint Backlog – basically, the to-do list for the sprint.

So when we say:

“The team selects an ordered list of user stories to comprise the Sprint Backlog for the next sprint, which will be achievable to satisfy the Sprint Goal...”

We’re really just saying:
👉 “Pick a realistic number of important tasks that, if completed, will help us hit our target for the sprint.”

Not too vague. Not too ambitious. Just achievable and focused.

☀️ Step 3: Daily Standups – Stay in Sync

Now the sprint is underway! But how does everyone stay aligned and avoid working in silos?

That’s where the Daily Standup comes in. Every day – usually in the morning – the team has a quick check-in (about 15 minutes) where each person answers three questions:

1. What did I do yesterday?

2. What am I working on today?

3. Is anything blocking me? (that is, am I stuck?)

Example:

“Yesterday I set up the login API integration. Today I’ll work on the UI validation. I’m blocked on getting access to the staging database — may need help.”

These standups keep the team in sync and surface blockers early so they can be addressed quickly. They’re not about micromanaging or showing off. They’re about visibility and support.

📉 What’s a Sprint Burndown Chart?

You might hear your team mention a “burndown chart.” No, this isn’t about things going down in flames (hopefully).

A Sprint Burndown Chart is a graph that shows how much work is left in the sprint – day by day.

• The y-axis is the amount of work remaining (often measured in story points or tasks)

• The x-axis is the number of days left in the sprint

The line should ideally trend downward as work gets completed – hence “burning down.” If it flattens out or slopes up, that’s a red flag that the team might be stuck, behind schedule, or not updating the board.

Think of it as a visual heartbeat of the sprint. You can learn more via a practical example in this video.

🖥️ Step 4: Sprint Review – Show What You’ve Built

At the end of the sprint, the team holds a Sprint Review (also called a “demo”). This is where you show what was actually built during the sprint.

• The Developers demo working features – live, not just screenshots

• The Product Owner reviews whether the Sprint Goal was achieved

• Stakeholders may ask questions, give feedback, or suggest tweaks

This meeting isn’t just for show – it’s a feedback loop. It helps the team validate that what they built is useful, usable, and meets expectations. If changes are needed, those get added to the backlog for future sprints.

🔍 Step 5: Sprint Retrospective – Look Back to Move Forward

Once the review is done, the team shifts focus from what they built to how they worked together.

Enter the Sprint Retrospective – a meeting to reflect on the process, not the product.

The team discusses:

• ✅ What went well

• ❌ What didn’t go so well

• 🔁 What could be improved next time

This isn’t about pointing fingers. It’s about learning, adapting, and continuously improving how the team collaborates.

The Scrum Master often facilitates this meeting and helps turn feedback into action items for the next sprint. For example:

“We underestimated testing time. Next sprint, let’s budget for QA earlier.”

The best teams take retros seriously. Why? Because even if your code is perfect, your process needs tuning too – and small process changes often lead to big gains.

♻️ Scrum Is a Loop

Here’s the rhythm:

1. Plan the sprint

2. Check in daily

3. Build and demo the product

4. Reflect and improve

Then do it all over again – with slightly better coordination and slightly more trust each time.

It’s not about being fast. It’s about being intentional, consistent, and collaborative.

Example Sprint

Let’s say, for example, that your team does 4-week sprints. (Keep in mind that Sprints can differ by team, nature of product, release cycles, and so on.)

Here’s the rough beat:

Scrum works in loops. Every 2-4 weeks (depending on your cadence and sprint cycle), your team should have working, demo-able software to show for it – even if it’s small.

And no, it’s not about “speed.” It’s about consistency, communication, and collaboration.

Who attends the Ceremonies:

Now lets dive deeper and understand practically how each of these ceremonies work:

Standups: Where You Talk Like a Human, Not a Robot

So how does the team actually stay connected day to day? That’s where standups come in.

Every morning, your team meets briefly – usually on Zoom or in a circle – and you answer 3 questions:

1. What did I work on yesterday?

2. What will I work on today?

3. What’s blocking me? Any impediments?

Example:

"Yesterday I cleaned up the signup validation logic. Today I’m working on the email verification flow. I’m stuck on SendGrid config – might need help setting up credentials."

It’s not about impressing anyone. It’s about keeping everyone in sync. Some days you’ll say, “I spent the whole day debugging a CSS bug that turned out to be a semicolon.” That’s okay.

How does it work?

The Scrum Master gathers everyone in a huddle room, the PO and Dev Team included, and opens the the Standup. They are the facilitator of the ceremony. Everyone gets a chance to answer the 3 questions above (usually about 2-5 minutes each). It’s not a full report – it’s quick. When one person is done, they pass it on to someone else.

This ensures there is team cohesion and transparency.

Here is a video example of a standup.

Sprint Planning

The goal of the planning meeting is to answer the questions “What are we going to work on, and how are we going to do it?” It is critical for the team to have a shared goal and a shared commitment to this goal before beginning this ceremony.

Participants should:

• Measure growth

• Sync with the Scrum Master

• Sync with the Product Owner

Sprint planning happens just before the sprint starts, and usually lasts for an hour or two. In this meeting, the team goes over a collection of user stories and discuss, plan, measure, and prioritize. This is where they decide what is going to be in scope for their upcoming sprint cycle.

The Product Owner will have a prioritized view of things in the backlog. They work with the team on each object or customer experience. Together, as a group they go through and make calculations, deciding to what they can commit.

What’s a User Story and Why Does It Sound Like a Children’s Book?

So you might be wondering: how do you know what to work on? What to build? So much work, so little time? Thats where user stories come in.

In Scrum, teams don’t just write vague tasks like “code the login.” Instead, they write user stories – short, human-centered feature descriptions that describe what the user needs, why they need it, and what success looks like.

Here’s an example:

As a user, I want to be able to reset my password, so I can access my account if I forget it.

User stories are the scaffolding of teamwork. They’re written with empathy, not just efficiency. And each one comes with acceptance criteria – a checklist that clarifies what “done” actually means:

• A “Forgot Password” link is visible

• Clicking it shows a form

• An email gets sent with a reset link

Once a story is agreed upon, developers break it down into tasks, like “build form,” “hook into backend,” or “handle email validation.” It’s collaborative, not prescriptive. And user stories have priority so you know what’s the most important and what’s the least.

A helpful rule of thumb many teams use is the Gherkin-style "Given–When–Then" format:

• Given some initial context

• When an event occurs

• Then a specific outcome should happen

This ensures that everyone – devs, testers, and product owners – shares the same understanding of behavior and expectations.

Here is a great video example thats outlines how to draft effective and powerful user stories.

What Counts as “Done”? Definition of Done and Why It’s Important

Now you might be wondering – how do I know when a task is done and can be closed out?

The Definition of Done is a type of documentation in the form of a team agreement. The Definition of Done identifies the conditions that need to be achieved in order for the product to be considered done (as in potentially shippable).

This is how we know that we "did the thing right". Meaning, we built the correct level of quality into the product. The Definition of Done is not the same as the acceptance criteria, which are written by the product owner to help us know we did the "right thing".

Every team has a Definition of Done – it’s not just “I pushed code.” It could mean:

• Code is written

• Reviewed by a peer

• Merged into main

• Tested on staging

• Possibly deployed

This clarity keeps teams honest and accountable. No “it works on my machine” energy here. The DoD sets a quality bar. It prevents ambiguity, rework, and “it works on my machine” moments. When every card on the board passes the same finish line, teams move faster – and trust each other more.

Everyone should know what done is in a team. Either its Done as per DoD standards or its not.

Here is a beautiful video highlighting the impotence of DoD.

Demos, Retros, and Saying the Hard Things

Once you’ve built the product, then comes demos (showcasing your work) and retros (analysis as a team on what when well and what areas to improve on).

In the retro, everyone’s encouraged to speak up:

• What went well?

• What didn’t?

• What should we try next time?

Example:

“We missed a lot of stories because we didn’t account for testing time. Maybe we buffer next sprint with fewer tasks.”

The goal is not to blame – it’s to improve. Over time, this feedback loop becomes gold. The Scrum Master usually facilitates, collects feedback (via tools like Parabol, Miro, or sticky notes), and helps turn insights into actionable experiments for the next sprint.

Over time, retros become the heartbeat of team evolution.

Here is a video highlighting the importance of a Retro and Sprint Review.

🧠 Why Retrospection Matters More Than You Think

The Sprint Retrospective is more than just another meeting. It’s a mirror for your team – a safe, structured space to pause, reflect, and improve together.

You discuss:

✅ what went well

❌ what did not go well

🔁 what could we do better next time

Great teams don't just deliver great software, they continually deliver better ways of working.

This is why many experienced Scrum practitioners consider the retro to be the most important event in Scrum. Code is deployed once, but process improvements grow exponentially, sprint after sprint.

Tools You Might Encounter

Scrum doesn’t require software, but real-world teams use a variety of tools:

• Jira – Tracks sprints, issues, velocity

• Trello – Simple board, good for small teams

• Slack – Where standups often happen if async

• Notion / Confluence – Docs, retros, notes

• GitHub Projects – Lightweight planning for devs

Don’t worry if you’re not fluent in these yet. They’re tools – you’ll learn them on the job.

If You’re Preparing for a Job, Here’s What You Can Do

• ✍️ Practice writing user stories from your side projects

• 🧪 Run a mini-sprint: Plan your weekend project, set goals, and “review” it at the end

• 🤝 Contribute to an open-source project that uses Scrum or Agile workflows

• 🧾 Write about what you learned – maybe as a tutorial (hint hint)

Final Thoughts

So to recap, Scrum is a simple yet powerful way for teams to work together, stay organized, and deliver results quickly. It runs in short cycles called sprints, where the team plans what to do, checks in daily, shows their progress at the end, and reflects on how to improve.

The four key ceremonies – Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective – help keep everyone aligned and focused. With clear roles and regular feedback, Scrum makes it easier to handle changes, solve problems early, and continuously get better as a team.

But scrum isn’t a magic spell. It’s just a way for humans to build complex things – together – without falling apart.

You don’t need to be a Scrum Master. You don’t need a certification. But if you understand how sprints work, what’s expected of you, and how to show up to meetings with clarity and candor, you’re 10 steps ahead of most.

Scrum helps teams talk, plan, build, and learn. And now? You can too.

If you liked this, please do share. You never know who it might help out.

Until then…keep learning, unlearning, and relearning!!!

When done right, the Sprint Review can be key to keeping your project on track. But badly run Sprint Reviews are worse than just the time they waste – they also reduce people’s trust in Scrum as a whole.

In this article, I’ll walk you through some clear, step-by-step ideas for making your Sprint Review more valuable.

What is a Sprint Review?

A Sprint Review is a short session held at the end of each sprint, usually once every couple of weeks.

It allows the team to show what they have completed via demos, get feedback, and decide what happens next.

When run well, the Sprint Review shows progress and builds trust with the people who have a stake in the product and project.

Sure, you can tell the stakeholders you are on track, but if they can see it with their own eyes in the Sprint Review, they’ll be much happier.

Who Should Be in the Review?

In short, anyone who wants to be. Anyone who is a project stakeholder in any capacity can and should attend the meetings.

The scrum team themselves are the core of the meeting, but there can also be Sales, Senior Management, other scrum teams, and Project Managers.

In short, if someone could have good input on a project or could get something out of learning something about a project, they should attend.

What to Do Before the Review

To ensure that the meeting itself runs as smoothly as possible, you need to make sure that everyone presenting is ready and has a demo ready to show.

In my experience, live demos don’t work. Well, sometimes they do, but mostly they don’t.

Get the people who have a demo to at least record themselves showing their workflow prior to the meeting. That way, if they insist on doing a live demo, they have a recorded video as a backup if it goes wrong.

You should also have a running order. Know who is presenting, in which order, and group them by similarity of topic. Who presents and when doesn’t really matter as long as the presentations are grouped together by topic.

For instance, if you have six engineers – two working on a Login Page, two working on new back-end service, and two working on database performance – make sure that your running order groups these three distinct areas together.

If two demos are fairly similar, you can explain the context once and then run through both demos back to back. Be efficient, as you have a lot of people in this meeting and everyone knows that meetings are expensive.

During the Review

The Software Engineers who have completed a piece of work will present the work to the other members of the scrum team (Product, QA, and so on) as well as all stakeholders who have attended.

After each Engineer has presented, anyone in the room is free to either ask questions or make comments about the work/presentation.

These questions can simply be to fill in knowledge gaps for people who know less about the project, or they can be questions about why a particular solution was chosen.

Product or more business-focused members of the audience may now give feedback on whether what was demonstrated matches the business intent of what was asked to be delivered.

Once all questions and comments have been addressed, the next Engineer will present their work.

In a Sprint Review, everyone is encouraged to speak, but generally it’s only Engineers who present. So the Engineer will present what they have worked on, then Product, QA, BA, and so on can give feedback and ask questions specifically about what the engineer has presented.

Example Review

Let’s take a look at an example review and what that may look like.

We’ll use the example above of having six engineers: two working on a Login Page, two working on a back-end service, and two working on database performance. In that case, you may have a running order like this:

Presentations:

1. Larry: User Exceeds Max login attempts and the user account gets locked after the fifth incorrect password. User has to reset password before they can login again.

2. David: User clicks forgotten password link and a link is sent to their email address. The user follows this link and is able to reset their password.

3. Premilla: Reporting Service consumes the “User Exceeded Max Login Attempts” event and publishes it to the reporting dashboard.

4. Akshat: Reporting Service consumes the “User Clicked Forgotten Password” event and publishes this to the reporting dashboard

5. Olga: An Admin User can view the reporting dashboard for a month and load the report within 3 seconds.

6. Trevor: An Admin User can view the events from multiple users combined in to one dashboard and load the report within 2 seconds.

As you can see here, the two login page user stories are demonstrated first, then the two reporting service stories, and then the two database speed stories. This requires less context switching for the members of the audience and means that context only needs to be given at the beginning of the first of the two grouped stories (that is, presentations 1, 3 and 5).

After presentation 1 (by Larry), Product may ask why he chose 5 retries as the maximum amount of retries before locking the account. Larry may have an answer, or he may not. Product can either ask to have a follow up on this later and find out what the industry standard is and apply that to Larry’s logic, or just leave it as it is.

After each of the six presentations, there could be questions, comments, and change requests by anyone in the audience. Typically this will then spark a conversation amongst the audience about the best approach.

For instance, in Larry’s example again, some may argue that they should not even be using a username and password, but instead should use an email address and magic link. This is the beauty of the review. You have a lot of smart people in a room bringing their own experience and expertise.

Actionable Takeaways

Here are some tips for what to show, how to show it, and what actually matters during the meeting itself.

1. Showcase Real Deliverables

First, always present working software or completed work rather than static slides. For instance, if you built a new login feature, do a live demo. This makes the review more genuine and shows tangible progress.

2. Encourage Open Feedback

Second, invite questions from everyone. Remind stakeholders that their ideas can help shape future work. Write down their suggestions, and confirm whether any changes should go straight into your backlog.

3. Keep It Clear and On Track

Third, maintain a simple format. For example, start with a quick overview of the sprint goal, move to demos, and end with a short discussion of next steps.

Avoid going too deep into technical details. If a topic needs more time, set up a follow-up chat.

4. Align on Next Steps

After that, update your backlog based on what you learned. If a feature needs an extra tweak, add that task right away.

This helps the entire group stay informed about the plan for the upcoming sprint.

5. Keep it short and end on Time

You should be reviewing one scrum team’s work for one sprint (two or three weeks).

If your meetings are running on for too long, it either means that your scrum team is too large (in which case, you should think about splitting your scrum team into smaller teams), or you are not efficient enough with your demos.

People’s time and attention is expensive and in short supply. Keep the meetings to no more than one ultradian cycle. I personally try to limit all of the meetings I run to a max of 90 minutes.

Lastly, set a firm limit for the meeting so that participants feel confident bringing their feedback without dragging out the discussion.

Wrapping up on time respects everyone’s schedule and keeps the team fresh for the next sprint.

In Summary

A Sprint Review gives stakeholders a real-time look at completed work, ensures alignment on what’s next, and gathers the feedback you need to grow your product effectively.

If you focus on showing real progress, inviting open dialogue, and keeping things concise, you’ll see a steady improvement in how your team delivers.

In his spare time, Ben writes his tech blog Just Another Tech Lead and runs a site creating forever-free online calaculators at CalculatorLord.com.

If you work on a Scrum team, you’ve probably heard of a daily scrum, sometimes called a daily stand-up. It’s one of the key events in scrum.

The “daily” usually takes place around the same time every day, and it should last around 15 minutes.

At first glance, it seems straightforward. When it’s your turn, you answer three basic questions. Job’s done, right?

Well, without a structure and someone to enforce that structure, a 15 minute daily meeting can turn in to a 45 minute chat.

What Is the Daily Scrum?

Scrum teams use the daily scrum to align and share their efforts.

Each person usually answers three questions:

1. What did I do yesterday to help the team meet its goal?

2. What do I plan to do today to help the team meet its goal?

3. Are there any obstacles in my way?

I call these the “classic three.” Yesterday, Today, Blockers.

From this explanation, if you’ve never attended a daily scrum, you might assume it’s just a trivial and pretty pointless meeting. But it can highlight important issues in real time.

For instance, if someone says, “I’m stuck waiting for a database script to finish,” the rest of the team can suggest a workaround.

Or if the product owner says, “We need to shift a feature’s priority,” everyone learns about it immediately.

Why Keep the Scrum Short?

In theory, the daily scrum lasts 15 minutes, give or take. Yet, many teams allow it to stretch to half an hour or more.

That’s risky.

When these meetings grow too long, people lose interest. Also, they might skip the next one, feeling like it’s a waste of time.

Beyond this, brevity encourages people to share only what matters most.

If someone dives into intricate details, it might derail the conversation.

This is not the space for describing every table in your database schema. It’s a moment to share your progress, highlight your plan, and let your teammates know if you’re blocked.

The Three Essential Questions

The daily scrum usually follows the same pattern. It’s predictable, and that’s a good thing.

Let’s expand on each question:

1. Yesterday’s Tasks: This is an update on what you finished. For instance, I might say, “I set up the new testing environment for our user login feature.” That helps the rest of the team see how tasks are progressing and whether I’m finishing my part of the sprint goal.

2. Today’s Plans: Next, we share what we’re about to tackle. For example, “Today, I’m going to fix a bug in the payment service.” That piece of information helps everyone see how the day’s work lines up with the sprint backlog.

3. Blockers: This is a crucial point. If something is stopping me from completing my tasks, I mention it here. Let’s say, “I need access to the staging environment, but I’m waiting on a permissions update to give me access.” This means if anyone on the team can fix that, we speed up progress.

In my teams, we usually have the Jira board open and associate each person’s update with the related story. This gives people a little more context. You don’t have to do this though – my teams just find it helpful.

How to Prevent the Scrum from Turning into a Status Meeting

A daily scrum is not just a status report. It’s a chance for the team to realign quickly.

But some managers treat it as a time to see who is on track. That can shift the focus away from cooperation. On the other hand, a team might treat it like a casual hangout without any structure. These extremes usually lead to frustration.

What’s the sweet spot?

It’s where the team focuses on tasks that lead to the sprint goal while also offering quick help when people get stuck.

The meeting should be about collaboration and the scrum team’s needs, not about pleasing a manager.

Also, if something requires a deeper talk, schedule a follow-up. For instance, you might say, “Let’s finish the stand-up, then we can chat about the modeling question after”.

If you find that your stand ups are getting too long, you as a team need to discuss why this is happening in the sprint retro and adjust.

A Typical Example of a Smooth Daily Scrum

Let’s paint a quick picture.

The team is working on a feature that handles user registration and payment processing. Each day, the daily scrum goes like this:

1. Developer A:

   • Yesterday, I cleaned up the user registration form.

   • Today, I’ll add form validation for email.

   • I’m blocked by a missing API key, so if someone can share that, I can move forward.

2. Developer B:

   • Yesterday, I tested the payment integration.

   • Today, I’ll fix a bug I found during testing.

   • No blockers.

3. QA Engineer:

   • Yesterday, I automated tests for the cart service.

   • Today, I’ll check the new user registration form.

   • No blockers, but I want to set up a quick chat about test coverage soon.

The entire process finishes in around 10 minutes. After the scrum, Developer A and Developer B might stay behind to swap that missing API key. Everyone else dives into their day. That’s it—short, sweet, and useful.

Common Problems That Disrupt the Daily Scrum

Let’s discuss a few pitfalls I’ve seen crop up over the years:

1. Going off on tangents: For instance, a developer might begin describing the entire architecture of a new microservice. The rest of the team is left wondering how that affects them.

2. Trying to solve every issue in real time: The daily scrum is not the place to debug code or solve other issues as a group. If something complex needs discussion, note it and talk after the stand-up with the interested parties.

3. Waiting for latecomers: Starting late can quickly become a habit. If people learn that the meeting really begins at 9:05, they start arriving at 9:10. The easiest fix is to start on time. People usually adapt once they see you’re serious.

4. No one mentions blockers: Sometimes, folks feel uncomfortable admitting a problem in front of the team. If that happens, the daily scrum loses its value. This meeting is precisely where you should feel safe to say, “I’m stuck here.”

5. Too many people in the meeting: In certain organizations, multiple teams join one daily scrum. That can lead to confusion. It’s better to keep each daily scrum small and focused. If you have a big project, you might break out into smaller Scrum teams.

Tips for Keeping the Meeting on Track

There are various ways you can help keep a daily scrum from devolving into a long, drawn-out meeting.

First, make sure you stick to 15 minutes (or shorter). A timer can really help. Some teams use an actual countdown on a screen, which can be fun. If you find that it’s consistently longer, it may be a sign that you have too many people, your team members need reminding about the format, and so on.

Second, make sure you have a capable leader who understands how to manage the scrum. Often, the scrum master or team lead can step in if the conversation strays. They might say, “Good point. Let’s park that for later.” This ensures the scrum doesn’t balloon into a brainstorming session.

You should also make sure the team is focusing on its sprint goals during the meeting. In addition to sharing tasks, remember why you’re doing them. For instance, if you know the sprint goal is to launch a new checkout flow, keep that in mind. This will help streamline everyone’s three questions.

Next, make sure you promote a culture of help. If someone mentions a blocker, invite the group to see who can help. This is a practical approach that fosters teamwork.

And finally, it can be helpful to use the scrum board. This board—whether physical or digital—helps people visualize progress. If your tasks are on sticky notes or in a tool like Jira, you can quickly show which tasks are done, in progress, or awaiting review.

Practical Ways Managers Can Support the Daily Scrum

Some folks ask if managers should attend the scrum every day. There’s no strict rule, but if you do join, here are some things to keep in mind to help your team stay on track.

First, make sure you let the team speak. The daily scrum is for the development team to share their plan and blockers. You as a manager should avoid turning it into a performance check.

Next, try to observe any ongoing or developing patterns. The manager can spot trends. For instance, if a certain issue keeps popping up, they might escalate it or allocate more resources toward solving it.

And try to offer help without dominating the meeting. The moment you sense a roadblock your position can solve—like a missing budget approval—step in. Otherwise, let the team own the meeting.

Frequently Asked Questions

1. How strict is the 15-minute rule?

   Pretty strict if you can help it. If your team is small, you may finish in even less time.

2. Do we need to stand physically?
   Some say it keeps the meeting short. Others aren’t able to stand, or prefer to sit. In my teams, the goal is brevity, so sitting or standing doesn’t matter as much. We also usually have a hybrid stand up where some people are in the office and some aren’t. For this, we all attend virtually.

3. What if we have nothing new to say?
   That’s fine. A quick “No updates, no blockers” is perfectly acceptable. The meeting might take only five minutes. Great—everyone can get back to work sooner.

4. Do we ever skip the daily scrum?
   Some teams do skip if everything is stable. I never do though, because it confirms that no new blockers have emerged. It’s like a brief pulse check. If there’s nothing to share, the meeting won’t last long anyway.

5. Who speaks first?
   Some teams pass a “talking stick” around in a circle. Others follow the order of tasks on the board. I’ve even seen teams do it alphabetically. I also like to mix it up by playing the “nomination game” where the person speaking nominates the next person. The method doesn’t matter, as long as everyone gets a turn. I do like to mix the ordering up though as it keeps the meeting a little “fresh”.

Conclusion

The daily scrum can be one of the most helpful parts of Scrum if it’s done right. It helps with open communication, early detection of blockers, and a sense of shared ownership.

Also, it reminds us what we’re aiming to achieve as a team (the sprint goal), which is easy to forget when everyone’s heads are down coding or testing.

Above all, keep it simple. Focus on yesterday’s progress, today’s plan, and any obstacles in your path.

If you need deeper conversations, schedule them right after the scrum with the people who care most about the topic. That way, you respect everyone else’s time.

In his spare time, Ben writes his tech blog Just Another Tech Lead and runs a site creating forever-free online calaculators at CalculatorLord.com.

I thought I knew everything about Scrum theory. But the one thing I didn’t know was that the framework is sufficiently resilient that not even a pandemic can stop it in its tracks.

Let me tell you why. But first, some background.

I am a technical project manager and Scrum master on the data engineering team for Major League Baseball. On a daily basis I eat, drink, and sleep all things Agile methodology, particularly Scrum.

My team works on solving complex problems in baseball stats and analytics. We build data pipelines, databases, data analyzing tools, and visualization tools to answer every question possible about traditional baseball stats (who leads the league in home runs?) and statcast stats (what batter has the highest exit velocity against The Yankees on two strike counts?).

Needless to say, some of the engineering challenges we face are not easy. And with difficult problems to solve, there is a heavy premium placed on excellent communication – it’s one of the key things we look for in hiring talent.

It’s one thing to build an intricate application that calculates home run distance based on on the launch angle and exit velocity of the ball, it’s another to write it all down and explain it to our key stakeholders.

Insert the COVID-19 pandemic into the fold

The season gets temporarily cancelled, our roadmaps get shuffled, and we are all forced to work from home indefinitely.

As the Scrum master for the team, I am all of a sudden thinking about how this will affect our communication, throughput, and quality of work.

Previously, we were all co-located in a small San Francisco office where everyone came to work each day. It was great – imagine one big room with an open floor plan where people just write code, bounce ideas off of each other, and watch baseball games.

But now, we are all communicating over Slack and Zoom, and I’m left wondering if things are going to slip through the cracks.

What did I do? I freaked out and started adding more meetings. This would solve our communication shortage, right? Just throw more meetings on everyone’s calendars!

So that’s what I did.

1. Happy Hour

I added a daily “happy hour” that was optional to attend. The goal was to provide a social outlet where people could talk about work or non-work related items in a casual, albeit still virtual, setting.

That one lasted about a week before people stopped going – but more to come on that later. First I want to go over the rest of the failed meeting attempts.

2. Happy Hour Part Two

The second was yet another Zoom “happy hour” with a slightly larger audience that included some folks from our New York office as well. That lasted even less than a week.

3. Leadership Overhead

The third bright idea: a “leadership” call between myself and the three dev leads where we went over in-flight projects and upcoming roadmap items.

I thought our roadmap would be ever fluid during the pandemic (which it was), so why not talk about it every week?

4. Additional Stakeholder Meetings

And finally, I set up additional touch point meetings with key stakeholders to make sure we were meeting their expectations and getting their feedback on our delivered code fixes and enhancements.

I thought I was taking a proactive approach to solving a problem that no Scrum team has ever gone through: going from a co-located work environment to full remote work while maintaining full productivity levels, strong communication, and high quality of work.

Little did I know, Scrum had this all covered and I freaked out over nothing.

Here’s why.

Scrum provides a framework for how teams can go about building products through iterative cycles of constant feedback and improvement. This framework calls for a variety of different meetings (or as my manager prefers, ceremonies), that facilitate these development principles.

And through these meetings, I came to realize that all of the problems I was trying to solve for, were in fact, already solved by Scrum.

Revisiting my list of additional meetings – let’s walk through why each became obsolete

1 and 2. The Happy Hour Meetings.

It is a best practice in Scrum to hold daily standups. Each developer on the Scrum team goes over what they did yesterday, their plan for today, and if they have any blockers or issues they want to flag.

Early into the working from home life, this daily meeting became a nice touch point to say hi to colleagues and have a bit of social time together. This often took the form of baseball trivia since most of us are big fans of the game.

And while the rules of Scrum say that daily standups should be no longer than 15 minutes, I figured this was well worth going over that. You see, while many Scrum masters are very rigid and treat Scrum as a "science", I am a bit more fluid and treat it more as an "art form".

3. The Leadership Meetings

The leadership meeting was to have a consistent meeting on the books to go over small and large roadmap items. It was to convene and prioritize items based on news about when the baseball season might return.

Again, I thought I was doing my team a service by adding this additional touch point. And again, I was wrong.

It’s another best practice in Scrum to hold a backlog refinement meeting at least once per development sprint. This meeting is used to review the upcoming bugs and features in the backlog and to prioritize them for future development cycles (sprints).

My dev team and I had been consistently holding these refinement meetings before the pandemic, and sure enough, this was the perfect solution for the problem I was trying to solve – it was there all along.

I quickly realized that we were just repeating ourselves in the leadership meeting. It was pointless to have both.

4. The Stakeholder Meetings

Since we were all working remotely, I figured we should communicate more with stakeholders to make sure we were all crystal clear about what they should expect from my dev team. By now, I’m sure you’ve guessed that Scrum also accounts for this in their guidelines.

The Scrum playbook calls for a demo at the end of every sprint where the dev team gives demos to stakeholders and asks for feedback.

We have been doing this remotely now, and it has had the same effect as always – it shows what we’ve been working on and it creates a forum for quick feedback from the people who have an interest in our product enhancements.

What I Learned

Hitting the fast-forward button to today, all of those aforementioned meetings have been cancelled indefinitely and my Scrum team is continuing to deliver consistent results to our stakeholders.

My bias toward taking action with additional meetings, while well-intentioned, only added repetition and clutter. Next time I guess I’ll think twice before trying to reinvent the agile methodology wheel.

There are two important lessons I learned while transitioning to working on a fully remote team during the pandemic that I hope are now obvious to you.

Firstly, it’s that the Scrum framework is resilient and already set up to work in almost any team environment. Its built-in touch points and meeting cadences are the perfect solution that were and still are staring me in the face.

My bias was towards action. But before actioning yet another team meeting, my bias should have been towards the question "why"? This brings me to my second takeaway.

I learned that before adding an additional meeting, you should ask yourself “what is this meeting trying to accomplish? What’s the goal? Is this not already being achieved by some other meeting or other form of communication?”

Surely, this litmus test will catch a lot of repetitive meetings and save a lot of people time on their calendars. Your team will be happier and more effective as a result.

I've been working as a Scrum Master since 2010. The most common questions I hear are:

• What exactly does a Scrum Master do?
• Do you really need the role?
• Is Scrum Master a full time job?

In this article I will answer these questions.

What exactly does a Scrum Master do?

The Scrum Guide describes the roles, events, and artifacts of Scrum.
Everyone who practices Scrum should read the Scrum Guide. It's the normative reference for Scrum. It's only about 20 pages, and it's free to download.

According to the Scrum Guide, the Scrum Master is a Servant Leader. So they're a leader who supports their colleagues in their activities. But not someone who just assigns tasks or bosses other people around.

The Scrum Master supports the Product Owner, the development team, and the rest of the organization.

The Scrum Master's support for the Product Owner

The main task of the Product Owner is to maintain and rank the Product Backlog to maximize the value of the product.

The Scrum Master supports the Product Owner methodically. For example, they help with the documentation of requirements, with prioritization techniques, and in communicating with the rest of the team and organization.

Everyone in the Scrum Team should share a clear vision and understand the direction in which the product will evolve. The team should also have a common understanding of the Product Backlog. The Scrum Master helps with that.

The Scrum Master's support for the Development Team

The Scrum Master supports the development team in delivering high quality products.

For example, they make sure that the team can deliver a working, integrated and automatically tested software at least once a Sprint. So for a 2-week Sprint, that's at least every 2 weeks, or more often.

If the team can't deliver, the Scrum Master has to take action.

In the Sprint Retrospective, the Scrum Master ensures that the team discusses how to improve delivery. Not theoretically, but practically. Step by step, in each Sprint.

If the developers can't remove an impediment, the Scrum Master helps. For example if tools need to be purchased for test automation and continuous integration. Or the team needs training courses for its developers.

Also, the Scrum Master supports the team in self-organization. In Scrum there is nobody who assigns tasks to the developers. Instead, the team members perform the tasks that are their own responsibility.

The Scrum Master supports the developers in making this happen, especially if they are not used to it.

Self-organization also includes dealing with conflicts. The Scrum Master teaches the team decision-making techniques and communication techniques, like non-violent communication.

The Scrum Master also hosts the Scrum Events.

The Scrum Master's support for the organization

The work of a Scrum Master is not limited to the team. They must also teach the organization how to interact with the teams.

For example, let's say that an important stakeholder approaches developers and makes them implement a feature that hasn't been agreed on with the Product Owner. Then the Scrum Master has to talk to the stakeholder and explain the influence of their behavior on the productivity and effectiveness of the whole team.

Furthermore, a Scrum Master helps with spreading Scrum in the organization,
and makes sure that everyone understands how it works.

Scrum is not a process that is just rolled out once and everything's fine. Scrum is about continuous improvement based on continuously observing what is going on.

Is the role necessary? Is it a full-time job?

The short answer is yes. I haven't seen a team that that's able to manage all the above mentioned tasks themselves, while at the same time focusing sufficiently on development.

But my experience is limited. It's quite possible that such teams exist, especially in smaller organizations and start-ups.

My experience as a Scrum Master is that I can usually take care of at most 2 teams. And then it's a full time job. It's not something that a developer does on the side.

In many organizations, this is seen differently. But they likely don't understood that a Scrum Master is a leadership position. And that has an impact on the effectiveness of the teams.

I believe that a lot of frustration that comes from sloppy Scrum implementations could be avoided. And one factor is to have an experienced Scrum Master.

To be a good Scrum Master, it's not enough to attend a certification course that just takes several days. Those courses are fine, but they only teach the basics. The real challenges come with practice.

Kanban was invented in the Japanese automotive industry in the first half of the 20th century. Inspired by how supermarkets stock their shelves based on demand, Toyota's goal was to reduce inventory and to improve the flow throughout their whole production system.

In his book Kanban: Successful Evolutionary Change for Your Technology Business, David Anderson described how to apply the Kanban principles to software development. These principles are:

• Start with what you do now
• Agree to pursue incremental, evolutionary change
• Respect the current process, roles, responsibilities, and titles

What does that mean for agile software development?

In my training courses, I ask the attendees what they already know about agile software development. Common answers are: "Work in Sprints", "There's a product owner", "Manage user stories in a backlog." People are influenced by the arguably most popular agile framework today, Scrum.

Scrum comes with its own predefined roles, events and artifacts. Scrum requires you to follow the rules defined in the Scrum Guide, if you want to call what you're doing Scrum. Kanban is different.

Kanban starts with the process that you follow in your company now. Visualize the steps on a Kanban board. They can include everything you do, from idea to delivery.

Each step becomes the title of a column on the board.

To track your day to day work, it's best to break it down into small items. Maybe user stories that can be implemented in, at most, 2 days. Write each item on a stickie note, and hang it on the board. You can use the vertical order on the board for prioritization.

The cards move from left to right. The people doing the work pull items that have been finished by the previous process step. When they have capacity to do so. So the developers in the example pull the Upload Image card into Dev when they have the capacity to implement it.

Pursuing incremental, evolutionary change

So you have created a Kanban board that shows your process? You are making your work visible, which is a great start!

To get the benefits of Kanban, you need to do some more things. You need to:

• Limit work in process and queues
• Observe and improve flow
• Collaborate effectively

Limit work in process and queues

Limiting work in process means: you set a maximum for the number of items you work on. That's called the Work-in-Process limit, or in short WiP limit. Here's the Kanban board with a WiP limit for some process steps.

The developers can work on 5 items at a time. At most. If their column contains 5 items, they are not allowed to pull items any more. This has two consequences.

First of all: it encourages people to finish their work, instead of starting more work. Started work that isn't finished bears risks. How happy will your customers be when you can't release your software as planned? Because you started to work on all these great ideas, but you didn't go through with them?

The second consequence of limiting work in process: bottlenecks become visible. When a process step starts work that it can't finish, people will feel it immediately. Because the next process step won't be able to pull items.

Apart from limiting the work in process, you should limit queue sizes, too. In the board above, they are shown as the dotted lines between the columns. It works the same way as limiting the work in process.

In summary: Stop starting, start finishing is the motto. From concept to delivery in as little time as possible.

Observe and improve flow

Observing a bottleneck can be painful at first. But at least you know where the major problems are in your process. And Kanban encourages you to improve the flow by removing the bottleneck. A consistent flow enables you to deliver more reliably, and that's good for all stakeholders, including developers.

To observe the flow, you record the time at which a card enters a process step. And the time at which you complete the process step. So you know how much time the card spends in each step, and in each queue between the steps.

Based on the data, you can set up metrics that help you to improve the flow. Common metrics include:

• Cycle time: the time a card takes from the moment a team starts working on it (i.e. Dev) to delivery (i.e. Release). Improving this metric can help you improve your time to market.
• Throughput: the number of cards that move through the system in a given time. Improving this metric can help you improve the performance of your delivery organization.

A common way to get an overview of how many cards are in which process step over time is a cumulative flow chart. Ideally, the number of cards in each step but the last stays roughly the same over time. The number of released cards should mount. When the chart deviates from that, you might have a bottleneck.

Collaborate effectively

The Kanban metrics are a powerful tool to analyze and improve what you're doing. But they are worthless without the people doing the work. Everybody involved in the process steps should be open to the transparency that Kanban creates.

People should work together constructively to remove bottlenecks, instead of blaming individuals. Look at the current state regularly. Are there any bottlenecks? Is there too much or too little work available for a certain process step? Is throughput sufficient? Are there other sources of discontent? What needs to be improved?

Agree on experiments that try out small changes to the system. Realize the changes. Later, look if the experiments worked out as expected. To be able to implement the changes, management support is often crucial.

When to use Kanban

Kanban is very flexible. It can be used in combination with Scrum, which is called Scrumban. It can be used outside of product development. You can even use it to plan a trip or organize what you do in your free time.

I found it especially helpful when working in Scrum Sprints is not possible or is difficult. Example: two companies where one is customer, and the other is supplier, and a hand-off is inevitable. Another example is when you're working on a product that involves both software and hardware, and multiple engineering disciplines are involved.

Kanban can also be used inside your company when development works in an agile fashion, but not all of the rest of the company does. It can be used to facilitate the cooperation between strategic planning and software development.

Don't think that just because you have trouble implementing Scrum, there's no way to become more agile. Kanban starts with what you do now. And if you take it seriously, it will help you improve. One small step at a time.

To learn more about agile software development, visit my online course. To keep up with what I’m doing or drop me a note, follow me on dev.to, LinkedIn or Twitter. Or visit my GitHub project.

• What is agile?
• What are some concepts you should know?
• Stories
• Epics
• Sprints

What is agile?

Agile is a software development methodology that stems from the idea of breaking up large amounts of work into smaller pieces. This gives product managers, developers, and any stakeholder a better understanding of the work.

Historically, software development was a slow process where major changes to requirements could put large strains on teams.

When following the agile methodology, the smaller chunks of work help teams become more flexible, and dare I say agile. And in the process it helps them deliver features faster and respond to changes quicker.

Example Jira project board from atlassian.com/software/jira

These ideas have been broken up into different frameworks of approaching this methodology. Two of the common ones are Scrum and Kanban.

For this walkthrough, most of these concepts follow along the Scrum framework, but there are certainly concepts that apply to both and others.

What are some concepts you should know?

I'd argue half of being productive as a developer in an agile world is simply understanding the terms. Typically the project manager runs the show, so if you can be on the same page with what they're talking about, it will make the process a lot easier.

There are books, courses, and certifications based around learning the nuances of the agile methodology. I'm not going to go deep into some of the philosophical aspects or some of the deeper parts, but I'm going to cover a good set of key concepts that will help you hit the ground running when you start your new job with an agile team.

Stories

A story is typically the smallest defined piece of work. This usually comes in the form of a new ticket that you create in the project tool you're using whether it's Jira or even Github Issues.

Expressing stories

When working on a project, you'll probably run into a variety of ways people express stories. But a good guideline is to work through the concept of the word "story" itself and explain the work that needs to be done in that way.

For instance, if you would like to provide the ability for the people who use your website to share a blog post on Twitter, you may want to write the story as: As a reader, I want to share the post I just read to Twitter.

Creating a new story in Jira

Using that pattern of "as a [person], I want to [action]" helps provide context as what state somebody may be in when visiting their site and what they're trying to achieve. This can be particularly helpful if you're developing features for people who are logged in that are different from guests.

Details and requirements

While the title of a story is an important representation of the work, you'll also want to provide additional specifics.

At a minimum, that should be done by adding a thorough description and a set of acceptance criteria that can help give the developer context and requirements. Depending on the team, this can also include tools like tags or categorizations that make it easier for the team to visualize groups of work.

Providing a strong set of requirements helps both the developer working on the story and the person reviewing it have a measurement to determine if it's actually complete. Without it, everyone's just guessing.

A good way to phrase these are: verify [requirement]. Back to my example of sharing a post on Twitter, maybe some of the requirements to that story would be:

• Verify when clicking the share button a new tweet is created
• Verify the tweet includes a link to the current blog post

Amount of work or level of difficulty

Each story is represented by a number of points. Those points are a way to express how much effort a team of developers expects one story to be. That effort can mean a variety of things though whether it's simply how difficult the team expects the work to be or the amount of risk or uncertainty a particular story has.

One way teams represent this is with the fibonacci sequence, where the amount of points can be 1, 2, 3, 5, 8, etc. Where a negligible text update might be 1 point, adding a new form to a page could be 3 points.

Typically you'll want to avoid pointing stories too high, as you get above 5 points, there's more than likely a way you can break up the work to make it more manageable. While you could easily create a massive 13 point story to accomplish all aspects of a feature, it usually makes sense to tackle the work in smaller, more focused chunks.

Either way, these points all add up together to give your team a rough estimate of how much work a group of stories would take to complete.

Epics

While stories have a goal of defining a bite-sized piece of work, epics are a way to group those pieces of work together to represent a feature.

Defining stories as a feature

A good way to explain this is with another example. If you're working on an application that requires the integration of authentication, you may want to create a new epic simply called "Authentication".

Inside that epic, you could find stories like:

• As a guest, I want to sign into the application with my email address
• As an authenticated user, I want to change my password
• As the security team, I want to prevent spam and abuse of user authentication

Example of an Authentication epic in Jira

With your epic defined, you're giving your team a path to calling a feature complete while also understanding the entire scope of that work. This is important when it comes to planning out the work to be done.

Defining your stories in your epic gives you a sense of how much work something takes, but it doesn't help you figure out how long it would take, which is where sprints come in.

Sprints

Sprints are a way of planning out how the work will actually get done. While similar to epics in that they are a way to group chunks of work, sprints typically represent a period of time in which a particular chunk of work will be done.

Time per sprint

A common way of defining a sprint is two weeks of work. During those two weeks, your team will have a particular velocity, or average amount of work you can complete, for an individual sprint. This velocity is represented by a number of points that is a sum of the average velocity of each of the developers working on that sprint.

Points per sprint

Though many fiercely argue you shouldn't use time to represent that velocity, points will roughly translates to an average amount of time of work for each developer. While 1 point for an experienced developer could be 1 hour, that same 1 point could mean 3 hours for a less experienced developer.

Example project roadmap from atlassian.com/software/jira

But once you have this number of points that your team averages in a sprint, you'll know how many story points you can expect to plan to be completed. This planning goes sprint to sprint as you spread out a group of stories or an epic so you can predict when a feature will be complete.

How agile fits with your team

Try to remember that the Agile methodology through Scrum, Kanban, or any other framework is just that – a framework. While it's probably a good idea to follow the process when you first start out, listen to your team and try to mold it to your own experiences.

Each team works a little bit differently and forcing a process onto that team can cause more harm than good, but there will always be a learning curve for any process. Fight the eye rolls until everyone gets the hang of it and have frequent retrospectives to see what works and what doesn't.

At the end of the day, the processes your team follows should mostly be invisible, working for you instead of against you. Find what works best for your team and share your experiences for others to learn!

What's your teams process?

Share with me on Twitter!

Scrum and Kanban are the two most popular project management techniques today in business. As a developer, I think it's important to understand these processes as you will likely be heavily involved in them if you are part of a team. By understanding, we can stay focused on solving problems and not be too frightened of some of the buzzwords.

I'm a developer by trade but my last employed role was in product management. I tried both of these methodologies to improve productivity and efficiency in delivering products and services in the best possible way. They also assist in making organizations quick to adapt to changes in demand for their products/services.

What is Scrum?

Scrum is a project management methodology designed for cross-functional teams of less than 10 members working on complex projects. Its primary goal is to use the team member's various skills to create a solution/product for the customer/end-user.

The word Scrum is derived from the game of rugby where players of both teams interlock and try to gain possession of the ball as a functional unit.

Scrum runs on three major pillars, transparency, inspection and adaptation. This methodology is based on the premise that the customer/end-user could change their mind about what they want or there could be changes which a planned approach cannot deal with.

The project is usually started with what information is available. Afterwards, changes or tweaks can be made whenever necessary while tracking the developmental process.

The project is broken down into distinct actions called sprints that have to be completed within a fixed timeframe or iterations. The average duration for sprints is usually two weeks to a month.

Progress is tracked through daily scrums which are 15 minutes fixed stand up meetings. This encourages close interaction and communication between team members rather than the traditional sequential approach.

What is Kanban?

Kanban is a visual project management framework which was created from lean software development process and used in Agile project management. The word Kanban is a Japanese word meaning Billboard and was derived from the lean manufacturing methods pioneered by the vehicle manufacturer Toyota in Japan.

It visualizes the work process and progress through Kanban Boards. It's used for products/solutions that require continuous delivery and aims to balance demand with available capacity (Pull system) rather than push out products to the market (Push system).

The aim of using Kanban is to remove bottlenecks during the production process so that the project can flow smoothly and still be kept within budget. It's usually used in combination with other agile methodologies like Scrum.

History

The Evolution of Scrum

The Scrum methodology was first mentioned in a 1986 Harvard Business Review article 'The New New Product Development Game' by Hirotaka Takeuchi and Ikujiro Nonaka.

The authors described this process they initially called the holistic or rugby approach as a new developmental process that would increase the speed and flexibility with which commercial products were brought to the market. They saw it as "good at bringing about innovation continuously, incrementally and spirally".

1993 saw the initial use of this methodology by Jeff Sutherland along with John Scumniotales and Jeff Mckenna at Easel Corporation. Two years later Sutherland and Ken Schwaber co-presented a paper describing the Scrum methodology at the Object-Oriented Programming, Systems, Languages and Applications '95 (OOPSLA) conference in Austin, Texas.

Schwaber also wrote the first scrum text in 2001 along with Mike Beedle called Agile Software Development with Scrum. That same year saw the two authors along with Sutherland and 14 other experts on Scrum draft the Agile Manifesto in Utah which specified the principles, features and values of this methodology.

The Scrum Alliance was created in 2002 by Schwaber to provide a governing body for the Scrum methodology as well as formal certification through the CSM (Certified ScrumMaster) program. Schwaber later left the alliance in 2009 to set up Scrum.org which is in charge of the Professional Scrum Accreditation Series.

Since 2010, a document called the Scrum Guide has provided guidelines for the Scrum methodology and has been revised regularly, with the latest version released on November 2017.

Evolution of Kanban

Kanban started life as a manufacturing methodology promoted on the factory floors of Toyota by Taiichi Ohno, who is known as the father of the Toyota Production System.

Ohno was looking for a way to increase productivity and reduce inefficiencies during the car manufacturing process while avoiding making products that couldn't get sold and lost money for the company.

In a quest to get a solution, Ohno would stumble on it during a visit to a Tokyo supermarket in 1943. There, he noticed that the products on sale were only restocked when they were almost sold out according to customer demand instead of through regular supplies from the vendor. This ensured that the supermarket had very little excess inventory and ran efficiently.

Ohno would bring this technique to Toyota thought it would take 10 years for it to be fully operational. A big part of this process would be the communication system which made use of visual cards called Kanban that illustrated to the workers in each stage of the vehicle manufacturing process what needed to be done, and the materials needed, in clear terms.

It also adjusted the number of vehicles manufactured to the demand by the public instead of utilizing the full productive capacity. This process was also known as lean manufacturing or 'Just in Time' production.

This helped standardize the production process, removed inefficiencies, and made Toyota nimble and flexible by avoiding the accumulation of excess products that couldn't be sold. This was a problem American auto manufacturers were also having.

This turned Toyota into a global auto giant. After its adoption in the automotive industry, the Kanban philosophy spread all over the world and into different industries.

Kanban would become popular in service/knowledge industries due to the work of David J. Anderson. He was an admirer of the lean manufacturing process who applied a pull system of development influenced by Ohno's Kanban philosophy while working with a Microsoft XIT Sustaining Engineering group in 2004.

The next few years would see Anderson and some other colleagues shape the features and principles of the Kanban methodology. The Kanban methodology spread through management conferences and talks and more companies began to adopt it.

Anderson collated his experiences with Kanban in a book published in 2010 'Successful Evolutionary Change for your Technology Business' which is regarded as the most comprehensive definition of the Kanban methodology for Knowledge workers.

The Scrum Principles/Values

Scrum boards are “Kanban boards” too, confusing eh?

The Scrum project management methodology became part of the Agile development approaches which spread in the late 1990s and early 2000s. These were an effort to find a solution to the high failure rate in software development.

The Waterfall Development approach used primarily before this point in the software industry was rigid and inflexible – product development had to follow rigidly laid down procedures and documentation.

Scrum allowed software developers the flexibility and freedom to respond to changes in development. It also called for the involvement of the customer in the development process rather than being a bystander.

This methodology later spread to other industries. Scrum has become the most used of the agile project management methodologies – research indicates that it is in use in 66% of all projects incorporating agile development methods.

Scrum is easy to understand and follow as it avoids rigid instructions and procedures. With Scrum, organizations can do whatever is needed to get the project done, adapting to circumstances that might suddenly arise. This flexibility is one reason Eric Naiburg, marketing vice president at scrum.org, calls Scrum the opposite of a to-do list.

The breaking down of projects into sprints makes it suited for complex undertakings while the involvement of the customer in the development process enhances transparency.

The Agile Manifesto

The Agile Manifesto set out to address frustrations among software project developers in 2001 and came out with four principles. Today these principles are the bedrock of the Scrum project management philosophy and have spread beyond the software industry. They state that projects should value:

• Individuals and interactions over processes and tools.
• Working products/solutions over comprehensive documentation.
• Customer collaboration over contract negotiation.
• Responding to change over following a plan.

Scrum Best Practices

• There are some best practices which underpin the Scrum methodology.
• We are ensuring Customer Satisfaction through early and continuous product delivery.
• Testing and incorporating product owner feedback daily.
• Welcoming and responding to changing requirements even late in the development process.
• We are working together with the customer on the development process.
• We are providing the support and environment for motivated individuals to get the work done.
• Emphasis on face to face communication within and to the team.
• We are measuring progress through a working solution/product.
• We are promoting development at a sustainable pace.
• We are enhancing agility by devotion to technical excellence and good design.
• Self-organizing teams being the best way to get the best architecture, requirements and designs.
• Having regular reflections on improving effectiveness through sprint reviews and adjusting actions to suit such.
• We are respecting the balance between the team members' professional and private lives to keep stress to a minimum.

Benefits of Scrum

The scrum methodology is the most widely used agile project management methodology for the following reasons.

Freedom of initiative — Professionals who love the freedom to take initiatives are in love with the scrum process due to its self-organizing ethos. This tends to boost team morale.

High-quality products/services — Products and services that are produced using the scrum process tend to be of a high quality due to the various iterations and improvements they have had to go through as well as customer involvement in the development.

Shorter delivery times — This is a result of the incremental development process which shortens the delivery time by 30%-40%. The involvement of the customer in the development is also a factor here.

Better return on investment — This is as a result of the shorter delivery times, better product/service quality and fewer defects as a result of continual feedback and the early testing.

Flexibility— Teams are able to react quickly to sudden changes in the market and reflect them in the product/service development.

Drawbacks of Scrum

Like everything else, the Scrum process does have its limitations. Here are some of them.

Need for expertise — Scrum requires professionals with expertise and training on the scrum methodology. This requires upfront investment by the organization.

Scope creep — The customer could request too many modifications on the product/project, which could turn out to be unnecessary.

Expensive — The need for high expertise during the scrum process as well as the constant events makes the scrum process expensive to operate

The Scrum Process

Scrum Teams

The process starts with the formation of a Scrum team to work on a pre-defined solution/project. These teams are usually self-organizing and cross-functional. According to Scrum principles, self-organizing teams are the best way to ensure optimal performance on a project as they can influence how the work will be accomplished rather than follow external directions.

Cross-functionality refers to the different competencies among the team members which enable the Scrum team to have all it requires to accomplish the project within and does away with the need for external help.

An ideal Scrum team shouldn't have more than 9 members to enhance the team spirit, closeness and effectiveness. It's also important that the team members are in the same physical location or are at least online constantly if they work remotely.

Scrum Teams deliver solutions in increments, incorporating the views of the product owner at each product's iteration. This ensures the constant availability of a functional product. There are 5 values or principles which every Scrum team should abide by in order to be effective.

• Commitment — Working towards the team goals at every sprint.
• Courage — Being able to do the right thing despite conflicts and challenges.
• Focus — Concentrating on the team goals and the sprint backlog exclusively.
• Openness — Being transparent with one another about the job and its challenges.
• Respect — Respecting each and every team member.

Scrum Roles

There are three distinct roles in any Scrum team: the product owner, the Scrum Master, and the Development team.

Product owner — This person represents the customer in the Scrum team and has the responsibility of ensuring the team delivers the project/solution/product according to the customer' s/end user's specifications. They have to communicate the end user's product requirements as well as the customer's feedback at each product's iteration. They also manage the product backlog which identifies the features of the product to be worked on.

Scrum master — This individual ensures that the team follows the Scrum principles and guidelines. They ensure that whatever is needed for the project is made available and take care of any impediments obstructing it. They also facilitate team events and ensure proper communication.

Development team — This comprises the rest of the Scrum team. They have to work together to provide a product/project using their various competencies. They organize themselves and choose their own path in getting the product delivered.

Scrum Events

Communication is vital in the Scrum framework. This is enshrined in the five events or meetings where information about the development process is exchanged regularly.

Backlog refinement — The product owner regularly reviews the product backlog which refers to the list of product features, the work to be done, and the sequence of delivery. They make sure that the backlog is properly prepared in a way that communicates to team members what needs to be done at each sprint.

Sometimes, the order of work has to be modified due to customer feedback or reviews from the development team. The review of the backlog, which is done in between the conclusion of a sprint and before the start of a new one, prioritizes features based on factors like business value, risk and date the features are needed. This review usually delivers the content for the next sprint.

Sprint planning — This is done at the beginning of a sprint to plan what needs to be worked on by the Scrum team. The smaller parts which a project is broken down into are called sprints. They could last from a week to a month.

The sprint meeting, which usually lasts an average of four hours for a 2-week sprint, has the team choosing the backlog items that can be completed during the sprint, how it will be worked on, and the goal for the sprint. These are all included in a sprint backlog.

Daily scrum/stand up — This is a quick daily stand up meeting that lasts a maximum of 15 minutes. The previous day's work is reviewed and challenges are identified by the team as well as individual members.

An individual is tasked with getting solutions to any challenges identified and any uncompleted work from the previous day is highlighted by the Scrum master on the scrum board.

Detailed discussions aren't allowed during scrum meetings. The strategy to be used for the day's work is also agreed upon.

Sprint review — This meeting which is held at the end of the sprint is used to review the performance of the team. If the work for the day is completed, the product's iteration is demonstrated and then presented to the customer/end-user along with the sprint backlog containing the 'done' items for their feedback.

The product owner can also make adjustments to the product backlog at this point.

The recommended duration for the meeting is usually a maximum of four hours.

Sprint retrospective — This is an opportunity for the Scrum team to reflect on how effective they were and what could be improved upon for better productivity the next time.

Scrum Artifacts

This refers to the commonly used tools in the scrum process. These are three of them used to record the progress of the Scrum team as well as details of the project.

Product backlog — Is a list of work that has to be done on the project by the scrum team. It contains the product requirements, features to be worked on and bugs that have to be fixed. It's overseen by the product owner and serves as a guide to the team. It's usually reviewed before it makes it into the Sprint backlog.

Sprint backlog — This list which is overseen by the development team refers to the list of product features from the product backlog that has to be worked on during the present sprint.

Team members sign up to handle tasks they can handle based on their competencies in the spirit of self-organization and commitment.

Sprint backlogs can be modified during a sprint but the end goal remains constant.

Product increments — This is the end result of the work completed during a sprint. It's usually added to the completed work from previous sprints.

This is usually according to what the Scrum Team defines and agrees as 'Done' status. Most times, this means the product is functional at an optimal level and ready to be delivered to the customer/end-user.

The Kanban Principles and Practices

The Kanban Principles

There are four core principles which form the bedrock of a successful implementation of the Kanban methodology.

Start with the present system — Kanban methodology stresses the need to avoid a culture shock by introducing a new system overnight. Instead, it can be brought into an organization and applied alongside the existing techniques.

This makes Kanban easy to implement and non-disruptive. Changes can then be implemented at a speed that everyone is okay with within a long gestation period while information about the current workflow and its inefficiencies are collected and analyzed.

Make changes incrementally — The Kanban methodology emphasizes gradual and small changes to the status quo. This will enable more buy-in from the organizational members that will be affected by the process, reduce uncertainty and unease, and in turn enable the organization to be turned around for the better as the evidence from previous incremental changes is apparent.

Respect the current workflow processes and roles — The existing work process, functions, and those in charge of them are not done away with immediately when the Kanban methodology is implemented.

The team will decide what roles should be modified, what changes should be introduced, and the right time they should be done. This is to ease the organizational transition among the members and make the incremental changes acceptable among them.

Encourage leadership at every level — Kanban recognizes that leadership qualities can emerge from anybody no matter the level they are in an organization. This is why team members are encouraged to act when there is a need for changes or to kick off initiatives instead of waiting for superior or senior management to order them.

This principle fosters trust and continuous self-improvement (Kaizen) among the team members, helping them to reach their optimal performance levels which will boost organizational productivity in the long run.

Kanban Practices

In order for Kanban implementation to be effective, there are six Kanban practices which teams have to put into action.

Visualize the workflow process — This is the first step when using the Kanban methodology. The process used to deliver the products/services by the organization as well as its flow has to be illustrated on a Kanban board which could be physical or electronic.

Each step in the workflow is represented by a column on the board. The different work items are denoted by Kanban cards of different colours. A collection of related work items can be bunched together using Kanban swim lanes.

The main aim of these is for all parties to understand the functioning of the workflow process from the customer request to the final product/service delivery as well as improve communication and collaboration. With this, different areas of the work process can be tracked and analyzed to identify possible impediments which can be worked on.

Limit the work in progress (WIP) — With Kanban, a manageable number of work items should be worked on at a time with a limit placed on the work in progress that can be handled. Work at hand should be completed before moving on to 'pull' in a new task.

Kanban discourages multitasking as it leads to wastage and inefficiencies. WIP limits in the column boards stress the importance of choosing the work the team has to do at the moment carefully as there is a limited capacity which has to be used efficiently.

Focus on the WIP also helps to reduce the cycle times (The duration from the customer request to the final delivery) for a particular product/service.

Manage the workflow — With the Kanban methodology, the various workflow stages and work progress in each of them are highlighted on the Kanban board.

Kanban emphasizes the management of the workflow process instead of the micromanagement of people with the main aim of its implementation being the smooth work process flow at optimal levels.

This enables the team to analyze the workflow process by measuring productivity/efficiency with metrics like cycle time and lead times. This makes it easier to spot any obstructions in the workflow process.

Most times, these obstructions are in the intermediate wait stages where the work has to change hands, but sometimes other factors like worker efficiency have a role to play.

Wherever they are present, adjustments are made in the work process to remove them and make the workflow better. This will enable the cycle times for the product or service to be reduced, ensuring faster turn around and the delivery of better value to the customers.

Communicate the process policies clearly — A big part of Kanban is the communication of policies and process rules on how work is conducted explicitly to all parties concerned so that there is a clear understanding of what is expected of each person. This help provides a standard against which performance can be measured and ensures quality consistency in the product/service delivered.

There have to be work process rules and guidelines for each column like who pulls what, entry and exit criteria for the column, when a task is done etc. which has to be visualized on the Kanban board. This keeps everyone with a visual reference in the organization as they work towards a common goal.

Get feedback regularly and implement it — Feedback is very important to the Kanban methodology. The review and analysis of the workflow stages on the Kanban board during daily stand up meetings are a good opportunity for this. Each of the different aspects of the workflow like delivery and operations should also be reviewed individually to track their progress.

Team members should also comment on their individual observations during the previous day. These daily meetings should be short and be straight to the point. Plans should be set in motion to work on all the feedback received. Getting all this feedback early in the process enables improvements to be made fast so as to improve cycle times and organizational productivity.

Always experiment and improve — The evolutionary change pattern of Kanban enables the use of the scientific investigation method which involves forming a theory, testing it and modifying it to be better.

The workflow process should be evaluated and improved upon continuously. New techniques can be introduced incrementally into the workflow process and observed, and then a decision should be made to keep or remove them depending on how much improvement they bring to the process through evaluating the metrics measurement.

Sometimes, these techniques just need some modification in order to perform optimally. Continuous improvement is the cornerstone of the Kanban methodology.

The Kanban Process

Kanban is a methodology that seeks to improve an organization's efficiency by applying visualization to the work process. It's based on the proven notion that the brain processes pictures more easily than words. With the visualization, areas of inefficiencies become apparent.

Kanban aims to improve the workflow process gradually and incrementally rather than quickly. This reduces the risk to the organization. It also aims to make the work process flow faster.

The Kanban Board

The Kanban board is the main tool for the visual representation of the workflow process. It enables clearer communication among all parties involved with the way information about the project/development process is highlighted through pictures.

Kanban boards can be in physical forms or in a digital/electronic form which is used for teams with remote members. The Kanban board usually comprises of three main columns:

• To do — Tasks that haven't been started are listed here.
• Doing — Tasks that are being worked on are listed here.
• Done — This consists of tasks that have been completed.

Tasks are represented by coloured sticky notes or cards. By representing the workflow process with pictures on the Kanban board, the efficiency of the workflow process can be measured especially with the aid of specialized Kanban software.

Where efficiency is lower than expected, impediments can be traced and then dealt with. This enables higher production efficiency and shorter product cycle times as well as improvements in the product/service quality.

Benefits of Kanban

Kanban is quickly being adopted by organizations in different industries globally. Some of the reasons for this include the following.

• Clear communication and transparency - The workflow visualization on the Kanban boards enables clear communication and lets everybody involved know what is expected of them. It's easy to track work progress which makes it easy to know what action is needed.
• Spot impediments quickly — The overcrowding of some of the columns can easily highlight where the work process is being slowed down, thereby necessitating adjustments.
• Flexibility — The ability to use Kanban in any system or industry and its philosophy of incremental change makes it a darling among many organizations desirous of continuous efficiency improvements. It is usually combined with agile project management techniques to make them more effective.
• Responsive to demand — Kanban enables capacity to be adjusted to match customer demands avoiding unnecessary wastage as well as the ability to respond to changes quickly.
• Focus and collaboration — Limited work in progress forces teams to focus on WIP instead of multi-tasking thereby enhancing productivity. Collaboration is also enhanced as organizational members help each other to remove challenges in discharging their tasks.

Drawbacks of Kanban

The Kanban methodology has its limitations –

• Ill suited for large projects — Kanban can be challenging to operate in a large scale situation.
• Misuse of Kanban board — The misuse or over-complication of the Kanban board can send the wrong signals about the workflow process which might result in costly mistakes.
• Wild demand fluctuations — Irregular product demands could disrupt the Kanban methodology as wrong signals could be sent as a result.
• Quality miscues— Kanban methodology drives down inventory levels to almost zero in a bid to reduce wastage. But when there's a quality issue with the final product or service, it could be difficult for the organization to react quickly as a result of the absence of an inventory buffer.

Similarities and Differences Between Scrum and Kanban

Scrum and Kanban are the most adopted productivity improvement tools globally but they are not really direct alternatives to each other like most people believe. They have some similarities but there are also differences between both of them.

Similarities

Both Scrum and Kanban are tools to improve productivity and efficiency as well as minimize wastage.

They are both based on the agile project management technique which emphasizes flexibility and ability to adapt to changes.

They also work on the 'pull' scheduling technique.

They both see improvements in product or service quality and delivery times are the cornerstone of both techniques.

They are both based on the self-organization ethos with team members taking their own initiatives and actions with every member being equal to each other and no orders coming externally.

Complex tasks are usually broken down into smaller, manageable parts.

Scrumban

In many organizations today, Scrum and Kanban are being used and combined in what is known as Scrumban. This was originally created for teams transitioning from Scrum to Kanban but has become a project management methodology in its own right. Under this methodology, the Scrum process is used but it's viewed through the lens of the Kanban improvement system.

A board similar to a Kanban board with coloured cards is used. Work is broken down into iterations. WIP limits are used here while team members choose the tasks they will work on since they are self-organizing.

On-demand planning is a feature of Scrumban. This is the application of planning techniques when new tasks are available rather than on a daily basis. Prioritization of tasks is done so that team members know what tasks are important.

Differences

There are many differences between Scrum and Kanban. This includes:

Definition — Scrum is a framework with specific rules and techniques while Kanban is a workflow visualization tool used alongside an existing system.

Training and management — Scrum requires a lot of education and training, as well as management and professionals with expertise. Kanban, on the other hand, can be easily understood by everybody which makes it cheaper to run and manage.

Change process — Kanban encourages incremental change and is suited for organizations with good, stable workflow structures while organizations that need wholesome change quickly should go for Scrum.

Usage — Kanban is usually used for smaller projects while Scrum is more beneficial for larger, more complex projects.

Roles — Scrum has three defined roles of scrum master, product owner and development teams. Kanban has no defined roles as every team member can take up available duties.

Duration — The Scrum process lasts for the duration of the project/development and is started again with a new undertaking while Kanban is a continuous effort as it is done with products/services that have to be continually delivered.

Teams — Scrum advocates cross-functional teams while specialized teams are the norm in Kanban.

New tasks/Iterations — In Scrum, new items cannot be added outside the preplanned tasks for the sprint even when the team has the capacity for such additions. In Kanban, new tasks can be worked on as long as the capacity is available.

Ownership — The sprint backlog in the Scrum process is owned by one Scrum team while the Kanban board can be shared by as many teams possible.

Productivity measurement — Kanban measures productivity using a product's/services' cycle time while Scrum measures this using velocity through the sprints.

Team goals — In Scrum, teams focus on collaborating and completing a pre-defined task while Kanban teams are focused on setting goals and reducing the cycle times.

Conclusion

This article doesn't aim to prove which is better between Scrum and Kanban as they are both productivity tools aimed at boosting efficiency. Rather it is aimed at providing an understanding of both tools so that you can make a good decision if choosing between them – or you can decide to go with both.

I personally prefer Kanban. But I think that's because a mentor of mine gave me a copy of 'Kanban: Successful Evolutionary Change for your Technology Business' which really helped me when I started needing to make my teams productive. It's definitely a book that should be in every office.

If you have any feedback or want to get in touch find me on Twitter @nialljoemaher.

References

https://en.wikipedia.org/wiki/Scrum_(software_development)

https://en.wikipedia.org/wiki/Agile_software_development

https://en.wikipedia.org/wiki/Kanban_(development)

https://en.wikipedia.org/wiki/Scrumban

https://searchsoftwarequality.techtarget.com/definition/Scrum

https://kanbanize.com/kanban-resources/getting-started/what-is-kanban/

https://kanbanzone.com/kanban-resources/what-is-kanban/

https://www.planview.com/resources/articles/what-is-kanban/

https://www.digite.com/kanban/what-is-kanban/

https://getnave.com/blog/kanban-history/

https://www.guru99.com/scrum-vs-kanban.htmlhttps://medium.com/@thorbjorn.sigberg/scrum-vs-kanban-c73dc70e8eefhttps://medium.com/ntask/kanban-vs-scrum-which-one-is-the-better-approach-to-use-in-2018-7503ee98dd0chttps://medium.com/@pavel.obod/kanban-vs-scrum-why-and-how-we-switched-from-scrum-to-kanban-8e524b6619bb

https://www.gliffy.com/blog/scrum-what-it-is-and-how-it-works

https://www.visual-paradigm.com/scrum/how-scrum-team-works/

https://skillcrush.com/2017/06/28/what-is-scrum-project-management/

https://stackify.com/what-is-scrum/

https://www.atlassian.com/agile/scrum

https://www.brighthubpm.com/methods-strategies/71133-weighing-the-disadvantages-of-the-kanban-system/

https://smallbusiness.chron.com/advantages-disadvantages-scrum-project-management-methodology-36099.html

https://www.yodiz.com/blog/kanban-vs-scrum-benefits-similarities-pros-and-cons/

https://leankit.com/learn/kanban/kanban-vs-scrum/

https://upraise.io/blog/scrum-kanban-project-management/

https://www.quora.com/How-similar-or-different-are-Scrum-and-Kanban

A few months ago, I got the Professional Scrum Master Certification (PSM I).

This is a trending certification nowadays, because most companies operate with some sort of agile methodology. So I wanted to share some tips that helped me get 98% on the first try.

In this article, will discuss both the fast and slow track. And I would urge you to lean more towards the slow track.

This is because the fast track, most of the time, will give you just enough knowledge to pass the certification. But this info is totally not enough to solve business day to day team problems with scrum. And that's a big part of what a scrum master does.

Still, some people just care about having the certificate itself, for their own reasons (for example, company KPIs). So let's get started with the fast track.

Fast track

The fast track should take at most 25-30 hours of preparation.

Read the scrum guide at least five times and internalize the concepts

Almost all of the questions in the PSM I exam are derived from details of the scrum guide text. Most of the time there are nexus questions too, but it is not that hard if you have conquered the scrum guide.

Learning the guide by heart is not the solution here. But you might need to memorize it to remember minor details you will never encounter again in your scrum master journey (which I believe is the case with most certifications) :-)

While doing this step, you should totally understand a) the processes of scrum methodology b) the why behind the processes.

For example:

• Why the daily scrum (or standup as most people know it) lasts for 15 minutes and not 20
• Why it's a bad idea for the CEO to join the sprint retro
• Why sprint ceremonies are not a chance to micromanage people

I believe if you read it thoroughly and mindfully 5-6 times, you are good to go.

Embrace the scrum.org fora

In there you will "meet" people from the scrum trenches. People who have made a living, maybe many years in a row, from scrum oriented activities and who know what works and what does not.

Reading the scrum.org fora helped me understand a lot "the why" behind the scrum guide.

Do the official open assessments

The official open assessments will test your understanding of the scrum guide and make you familiar with the actual exam environment. They are great practice for PSM I.

I think a good portion of the questions that you will encounter in the open assessment will be similar to the ones in the exam.

I recommend that you take the open assessments many times. The more the merrier.

A popular stop criterion is when you have achieved a 100% score five or six consecutive times.

Do the mock tests from Mikhail Lapshin

Mikhail Laphsin is a software architect and he's very passionate about scrum as well.

Because of that, he had created one of the best simulation tests out there, which 100% follows the scrum guide.

There are not multiple versions of the test (at least that was the case when I was taking it). But taking it and checking the explanation of your wrong answers will supercharge your ability to tackle the actual exam.

The slow track

This track will keep you busy for about 3 months. You can stretch it as much or little you want. I assume you have gone through the fast track as well, before starting the slow.

Don't forget to check the official reading guide too, when on the slow track, and add any resources you find interesting in my suggestions.

Reflect on your current scrum experience

You can get the scrum master certification even if you've had no experience with scrum before. But it will make your life way easier if you do have some experience.

So if you are one of the lucky (experienced) ones, think what you are doing right and what you are doing wrong in the scrum team you are part of.

Just keep in mind - there are some opinionated people who don't know what scrum is all about. They think it's a web development framework or a book of pasta recipes. It's ok - let them do their thing, and stick to your plan to become a great scrum master.

When you do, you can be opinionated as you want. Until then, I suggest you focus on the collective experience of the community.

If you don't have experience with scrum, a great free resource for a pretty good and interesting introduction is this Scrum Training Series.

Blogs

Similar to the scrum.org fora, blogs can give you a great perspective from a working scrum master / agile coach.

Some articles might be overkill for a new scrum master, so don't get discouraged if you don't get some of those.

My other favorite one is Serious Scrum.

Books

Did you think you would escape? :) Here are some of the best scrum books I have found out there and I would suggest that you read.

• Software in 30 Days
• Essential Scrum: A Practical Guide to the Most Popular Agile Process
• The Skilled Facilitator: A Comprehensive Resource for Consultants, Facilitators, Coaches, and Trainers
• The Professional ScrumMaster’s Handbook - Break the Chains of Traditional Organization and Management
• Toyota Production System: Beyond Large-Scale Production
• The Serving Leader: Five Powerful Actions to Transform Your Team, Business, and Community
• Scrum and XP from the Trenches

Other assessments

If time allows and you are not burned out yet :-P , doing the nexus, scrum developer and product owner open assessments will help you get a wider picture of the framework, from various angles.

Of course, you don't need to get consistently perfect scores. A couple of runs with a "pass" is more than sufficient in my opinion.

Book a class

This is a bit overkill if you ask me, and I would never take a class for PSM I (PSM II or III are more eligible for that kind of training). But I don't want to influence your personal style of learning.

You can find all the trainers here. If there is no one in your country or you don't want physical presence due to the pandemic, maybe you could request Skype/Hangouts courses.

I don't know anyone who has done it, so if you have any interesting feedback to share, please do, I would be glad to hear it!

Conclusion

Thank you for reading this article. If you are new to the field, I wish you all the best in your journey as a scrum master. If you are more seasoned I would appreciate any feedback on the resources. Enjoy your study in any case!

User stories are a great way to plan development work. In theory. But how do you avoid getting burned in practice? I propose a radically simple approach.

Here's a popular template to describe a user story:

Here's an example user story:

User stories look at software from a perspective of user value. After implementing a story, the developers can get feedback from users whether they're satisfied or if there's something they'd like changed. That's the core idea of agile development.

Good user stories follow the three Cs: Card, Conversation, and Confirmation [1].

Card means: user stories are short. They focus on the value provided to the user. You can write them on an index card, or a Post-it. Of course, a Post-it doesn't contain all the information necessary for development.

So the team developing the software has conversations about the stories. Input from users and business stakeholders is necessary, but developers bring their ideas to the table as well. It's important that everybody keeps an open mind in these discussions.

The team documents the results of the conversations as acceptance criteria. Checking the acceptance criteria later serves as confirmation that the team has implemented the story correctly.

Acceptance criteria and INVEST

The acceptance criteria should answer questions like:

• What are the possible user inputs?
  For example: "The payment options are MasterCard, Visa, [...] PayPal."
• How does the system react to user input, or a business relevant event? Under which conditions?
  For example: "When the user enters a wrong credit card number, the system shows the following error message: [...]"

There are many ways to document acceptance criteria. Bullet points, sketches, examples, tables. Development starts a few days after the conversation about the story. So developers need just enough documentation to remember the conversation.

How does a team check if a story has a good enough quality to start implementing it? The INVEST criteria define a quality checklist for each story [2]:

• I for Independent. The story can be implemented independently of other stories. This facilitates priority changes.
• N for Negotiated. The conversation between developers and stakeholders about the details of the story has happened.
• V for Valuable. The story provides visible value for users. In contrast to implementation tasks like querying the database, for example.
• E for Estimable. The developers can estimate the story.
• S for Small. The story can be implemented quickly. In Scrum for example in a Sprint.
• T for Testable. The story is so concrete that the team can derive test cases.

The problems in practice

I like user stories. In product planning, they shift the focus from technical details to users and their needs. That's good.

And yet, in my work as an agile coach and trainer for agile approaches, I've started questioning the common way people deal with them.

I've seen backlogs with hundreds of stories that became extremely hard to manage. I've witnessed people use the terms "feature", "epic" and "business requirement" without sharing an understanding what that even means. I've heard endless discussions about detailed acceptance criteria, and how to slice stories based on them. It was frustrating.

I claim there is an alternative. A simple way to avoid all these traps. First, you need to understand that there are two fundamental levels of user stories.

Goals deliver value, but can't be implemented

In one of my courses, I ask questions like: "What can you do with a web shop?"
The typical answers are: "Buy a product", or "Order products".

What the participants talk about are goals. If we were a team developing a web shop, we might come up with the following user story:

Is this goal level story valuable to the user? Yes! It reflects the needs of the web shop customer.

Can you implement this goal directly? No! In order to implement a goal, you need to derive steps to reach it first. For the story "Buy Product", the steps might look like these:

Each step could be documented with the user story template: "As a web shop customer, I want to enter the address so that the product is shipped to me."

Can you implement this step level story directly? Yes! As soon as you have clarified the acceptance criteria. But is it valuable for the user? Without the other steps, no.

Value only emerges when the goal has been reached. Each step represents progress towards the goal. But independently, the step has no value. Does it make sense to use the story template for it then?

A radically simple approach

The stories at the goal level are coarse grained. They can be used for long-term planning, without wasting effort on details:

You can often realize good user stories at the goal level independently of each other. And they deliver value. They are Independent, Negotiated, and Valuable. But they are not Small, easily Estimable and Testable. Because you cannot define acceptance criteria for them without talking about steps.

The stories at the step level are Negotiated, Estimable, Small, and Testable. However, they are not Independent and do not provide Value alone.

How do you combine the two kinds of stories into one simple approach? Here's my proposal.

The team picks a goal, say "Buy product". The team then reflects: "What is the simplest way to reach the goal? And how can we reduce architectural risks early?"

Let's assume that the team sees the greatest risk in the communication with PayPal, because they've never implemented an interface to PayPal before.

So what does a simple way to get to the "Buy product" goal look like? The team puts goal level story, step level stories and acceptance criteria as stickie notes below each other:

Here's what the acceptance criteria say (green stickies). There is only one fixed product that can be ordered. No search, no choice. The user interface is basic, and only allows users to pay with PayPal.

These are the first steps that the developers implement. Once the developers have implemented a step, they demonstrate it to company internal stakeholders. At latest when a goal is reached, the team involves users. Getting feedback and deriving insights for further iterations is crucial.

In later iterations, the team adds and changes stories. Examples include: more products, a search capability, and new payment methods. Or the team picks another story as a goal. Whatever is most valuable and makes sense at a given point in time.

Summary

You focus on a few goals to look further ahead. But you only discuss the acceptance criteria of the steps that you will implement in a few days. You implement the steps and gather feedback. You use the feedback to inform what you will develop in the future.

That way, everybody has a clear idea of what happens in development. You avoid wasteful discussions. And you keep backlog management to a minimum.

I've followed this approach many times. When everybody involved is on board, it works great. It makes development a joy.

And that's it.

Sources:

[1] Ron Jeffries 3Cs: https://ronjeffries.com/articles/019-01ff/3cs-revisited/

[2] Bill Wake on INVEST criteria: https://xp123.com/articles/invest-in-good-stories-and-smart-tasks/

To get the basics of agile software development right, visit my online course. If you want to keep up with what I'm doing or drop me a note, follow me on dev.to, LinkedIn or Twitter. Or visit my GitHub project.

The desired benefits of agile development are many. Customers are happier and more willing to buy. Lead time from idea to delivery is shorter. Employees are more motivated and more productive.

Sounds good, doesn't it? In practice, certain behaviors stand in the way of the benefits. As a scrum master and agile coach, I see the same anti-patterns in many companies over and over again. Today's anti-pattern is about project budgeting and contracts.

Fixing the scope - not a good idea

In many companies, the scope of delivery must be decided on first. Then someone estimates the effort and calculates the necessary budget. Finally, there is a go or no-go decision for the project.

It is similar for many customer supplier relationships. First, a contract must be set up that describes exactly what will be delivered. Otherwise there is no order.

How else could it be? How else can you, as a customer, be sure what will come out in the end?

As an agilist, here's my answer. Customers can't possibly know the exact end result in advance. Software development is full of surprises. The requirements of today are history tomorrow.

It's important to recognize the tension between predictability and changeability. You can't have both: perfect predictability of the end result at the beginning and maximum consideration of change requests later.

What you can do instead

At the beginning of agile development, it is sufficient for stakeholders to agree on a product vision, and maybe a rough roadmap. Funding can be done incrementally, sprint by sprint.

But what if this is not possible in your company? What if the stakeholders don't want to give up the illusion of safety that comes from clarifying requirements early?

Well, it's a waste of time to specify details of requirements that will change later. So what to do?

You can agree on user stories in advance. That makes sense. But don't define the acceptance criteria! Clarification of details is postponed to development, shortly before implementation.

The advantage: you can react to lessons learned from development and new customer needs.

Change management done right

Either at the beginning of a project or during contract negotiation, stakeholders should agree on the mode of cooperation and the handling of changes later.

It is important to follow a few important principles.

If there are changes, a change management process that evaluates each change individually is NOT enough. Instead, a change should be related to other changes.

For each change that is implemented, either

• take another requirement out of scope, or
• increase the duration of the project.

During development, individual elements can therefore be replaced by elements that are equivalent in terms of development effort. Scrum supports this with the Product Backlog–by pulling a backlog item up, the other elements automatically have less urgency.

If you want to know more about agile contract design, I recommend you have a look at Money for Nothing and Your Change for Free.

To get the basics of agile software development right, visit my online course. If you want to keep up with what I'm doing or drop me a note, follow me on dev.to, LinkedIn or Twitter. Or visit my GitHub project.

The hard parts of Scrum and how to work around them. Further inspiration can be found here: ScrumBut.

Only the developers estimate

According to the Scrum Guide, only members of the development team are allowed to estimate development effort. Neither Scrum Master, nor Product Owner.

As a Product Owner, you should therefore subtly influence the estimates in your favor by asking questions like: "You can do that in two weeks, right?" Or: "I can't imagine that this is a lot of effort. Does anyone else see that?"

That way, you stay in control even when the going gets tough!

Done

Scrum calls for a potentially shippable product increment at the end of a Sprint: executable, tested and integrated software. Because this is one of the hardest parts of Scrum, there are several workarounds to make life a little easier.

First, learn to appreciate other artifacts as Sprint results as well. How about a completed analysis or architectural document? For this to work, you only need to adjust the Definition of Done.

Second, most importantly: do not forget the phases before Scrum and after Scrum.

Before Scrum, a planning phase of several months should take place, in which the project is approved and its scope is fixed.

After Scrum, you should have a test phase of at least several weeks until the product can finally be delivered. This workaround is particularly useful if you do not use any form of automated testing, integration or deployment.

The product owner sets priorities

According to the Scrum Guide, the Product Owner has the final say when prioritizing the Product Backlog.

This is uncomfortable. It would give the lower level management folks huge decision-making power. Real managers keep away from developers, in order to be able to make unpleasant decisions and enforce them.

Fortunately, there are now established roles such as the "Proxy Product Owner". Rightly applied, that role has no decision-making authority. PPOs merely pass on the announcements from the top to the developers and "take the responsibility" if something goes wrong.

So - these are my "recommendations" for you today.
What are your favorite Scrum hacks?

To get the basics of agile software development right, visit my online course. If you want to keep up with what I'm doing, follow me on dev.to, LinkedIn or twitter. Or visit my GitHub project.

In my work with agile teams and as a trainer I often hear statements about user stories that cause problems in practice. Time to get rid of the most common myths.

Myth #1: In Scrum, you document requirements with user stories.

The Scrum Guide leaves it open how backlog items are documented. I like user stories because they shift the perspective from the system to the user. But they are not mandatory. And they should be used more for conversation than f or documentation.

Myth #2: If you write user stories, you have to use a certain template.

You probably think of: As a user I want function so that fulfilled need.
The user story concept had nothing to do with this template at the beginning. Later the template became popular. It's possible to document user stories informally. Don't get hung up on the template.

Myth #3: User Stories are estimated with Story Points.

As a Scrum Master, I watched teams go crazy with discussions about story points, estimates and velocity.
There is a simple alternative. The team agrees on small stories. So 1 or 2 days to implement them. Then after the sprint, the team counts the stories it has finished. There's the velocity.

Learn more about how to deal with user stories effectively by visiting my online course. If you want to keep up with what I'm doing, follow me on dev.to, LinkedIn or twitter. Or visit my GitHub project.

What has not been declared dead already? Test Driven Development was buried years ago. Still, it continues to spread. Of course, Agile is dead as well. But even traditional companies come into contact with Scrum. The dead continue to live, but declaring something dead is always good for a snappy headline. In that sense, witness how I destroy epics as an agile practice.

What are epics?

The term is vague. This has advantages. Epics are more for communication than specification. The vagueness makes them versatile. But there is a risk of misunderstandings. I stick to Mike Cohn’s definition:

A Scrum epic is a large user story. (Source)

I use the term like this: An epic is a story that is too big to be implemented in a Scrum sprint. The items at the top of the Product Backlog are thus not epics, but little stories. Down in the backlog you will typically find epics. Over time, the epics are “sliced” into stories that can be pulled into a sprint.

That is what I have taught for years in my training courses. It seems to be the general consensus. Intuitive at first glance. I’m here to explain why it’s not practical.

3 impractical ways to deal with epics

So far, I’ve come across three ways companies deal with epics. None of them is practical. Let’s call them:

Dissolution

1. Dissolution

Links

2. Links

Trees

3. Trees

1. Dissolution

The principle of dissolution is simple. An epic is completely broken down into its components, the individual little stories.

For example, an epic “Book flight” of an online flight portal can be broken down into the individual process steps. So “Log in”, “Search flight”, and so on. Every process step becomes a story. The team estimates the story. As long as it is too big, the team continues to slice it. Once all stories are small enough to fit into sprints, the team deletes the epic and starts development for the stories.

It’s the underlying idea of completeness that bothers me. The dissolution suggests that a topic can be completed with a predetermined scope.
But if changes to the stories are possible during development, you can’t define all the stories upfront.

The Scrum Guide says:

A product backlog is never complete. […] Requirements never stop changing.

If you have to deliver a fixed scope, stop pretending. Forget about epics, and describe the detailed requirements upfront. Just don’t claim to be agile then.

2. Links

If you don’t dissolve your epics completely, it makes sense to use links. The epics remain, down in the backlog. You link new little stories to the epics from which they derive.

The risk is that over time, the amount of epics increases. The backlog becomes bloated. It contains epics that you don’t need any more. The stakeholder is no longer in the company. Or the topic is no longer relevant.

Of course, you can clean up your backlog from time to time. I regard this as non-value-added work. And you can avoid it, as I will describe later.

3. Trees

Another way is the depiction of epics and stories as a tree:

Depiction of epics as a tree

You group the little stories by epic. Not a bad idea. But what you lose is the ordered list of the backlog. How do you determine the implementation order then?

Of course you can use a digital tool that supports both views. The risk: you invest too much time and effort in the tools. What are the views? What are the attributes? What is the underlying data model? Interesting questions. But in an agile approach they should not have high priority.

In summary, the idea of grouping is good. But doing it is time-consuming.

The alternative to epics

There has long been an alternative. It is even mentioned in the same blog post by Mike Cohn, which I linked above.

I am talking about themes.

A theme can be thought of as an additional attribute of the stories. Normally, several stories share the same theme. The story “Search flight” could have the theme “Book flight”. A snippet from the backlog could look like this:

User Stories with theme

Themes are not managed as separate backlog elements. This eliminates the cleanup work discussed in the Links chapter. That’s good.

But what you lose is the process of gradual refinement from the big epics to the stories that can be implemented in a sprint. That’s bad.

Luckily, there are practices that make it possible to do this refinement outside of the backlog. One way to identify themes is a use case diagram:

The nice thing about such diagrams is that they show the “Big Picture” due to the high level of abstraction and the graphical representation. For that, a backlog is unsuitable.

The use case names later become themes in the backlog. But how do you get from the use cases to the stories? For this, Jeff Patton's Story Mapping is a good fit:

The top two lines of the example map show the use cases “Book flight” and “Manage profile” and their basic flow. Under the individual steps, the team hangs the alternatives: other processes, errors and so on. These yellow notes are called user tasks.

In Backlog Refinement, the team derives the stories from the user tasks. A task can serve as the title of the story. The team adds details like acceptance criteria to the stories.

The consequences

Applying this alternative approach has consequences. For example, the Product Backlog will only contain stories for the next 1–2 sprints. So maybe 10–20 stories.

All activities like further prioritization, estimation and elaboration of the acceptance criteria only take place with these stories. As the 10th agile principle says:

Simplicity — the art of maximizing the amount of work not done — is essential.

If management wants to have insights into the progress of development, this is possible on three levels:

• Use case diagrams or themes provide the long-term perspective for management. For 1 year, or even beyond. But: they are not suitable for specifying details.
• Story maps form the basis for release planning. Stakeholders interested in the release create the story map with team members. (Due to new findings, the scope may change during development.)
• Those who want to have a deep insight and influence the details during development participate in Sprint Review and Backlog Refinement.

Only at low altitude, we see the details. And the Product Backlog is basically like a shopping list. Would you write down what you want to buy in a year?

Last, but not least, the death of epics heralds the dying of consumerism. If you want something, you have to agree with the team and work closely together.

Post mortem

In the discussion with colleagues, they pointed out that even after a dissolution of an epic, small stories can be added. That’s right, and for me it’s an acceptable solution. What is lost in this case, however, is the “Big Picture” that I have shown in the use case diagram.

Ultimately, the suitability of a product for users determines its success. Not how it was made. This applies to all development practices, including epics.
Maybe you have come up with a sensible way to deal with epics?

Learn how to manage your Product Backlog effectively by visiting my online course. This article was first published on HOOD Blog in German.

Many development teams are too familiar with the frustrations of unsatisfactory acceptance criteria or even the lack of criteria itself. Defining no requirements is like preparing for battle without a plan of action — the team has taken more steps toward failure than success. I offer specific suggestions in crafting acceptance criteria that can improve any agile process.

First, let’s quickly define acceptance criteria.

Acceptance criteria are the “conditions that a software product must satisfy to be accepted by a user, customer or other stakeholders.” (Microsoft Press)

Easy enough, right? Not quite. At this point, I would ask myself if this is where my definition of acceptance criteria stops. In addition to the definition above, any product owner should have answers ready for the following questions:

What do these conditions look like? Who creates these conditions? How many conditions should there be? How are outcomes measured?

Generally, acceptance criteria are initiated by the product owner or stakeholder. They are written prior to any development of the feature. Their role is to provide guidelines for a business or user-centered perspective.

However, writing the criteria is not solely the responsibility of the product owner. Acceptance criteria should be developed as a joint effort between the development team and the product owner.

Crafting these criteria together helps the development team understand the desire featured. It also helps the product owner catch missing details. Additionally, the owner gains a better understanding of feasibility, complexity, and scope.

_Image by [Maryna Z. & Dmiriy G](https://rubygarage.org/blog/clear-acceptance-criteria-and-why-its-important" rel="noopener" target="blank" title=").

Formatting acceptance criteria

Criteria can be written in a variety of formats. Most teams lean towards two specific types: rule-oriented or scenario-oriented.

Rule-oriented requirements are straight-forward. They list out observable outcomes. “Display statement balance upon successful authentication.”

On the other hand, scenario-oriented criteria tend to follow the “Given…When…Then…” template. This was derived from behavior-driven-development (BDD). This requirement outlines the expected observable result. This occurs when a particular action is executed given some context.

3 characteristics of effective acceptance criteria

1. Testable with clearly defined pass/fail results

Have testable criteria. This allows testers to properly confirm that all of the desired conditions have been fulfilled. If criteria were not testable, then there would be no way for verification. These criteria should either be met or not met. A developer should know the point in which the criterion has been achieved. Any ambiguity may prolong effort on the story.

For example, an acceptance criterion states “increase the number of entries available in a drop-down menu”. The developer would have no idea how many new entries to add and may take the liberty to assume a number based on his experience with the product. Likewise, a manual tester may take the same liberty and assume a different definition of increase. This results in a confusion that will circle back to the product owner.

2. Unambiguous and concise

This is where writing acceptance criteria become an art. Academic essays stress the importance of clarity and succinctness. Similarly, writing acceptance criteria mandates the same level of organization and care.

Similar to writing a literary piece, the audience must be kept in mind. Those reading the acceptance criteria must understand what is written. Otherwise, those words are completely useless. If they are long-winded and filled with jargon, then the main points of the outlined conditions may not come across. Many people can overlook essential details in a sea of words when pressed for time. Even when not pressed for time, many people can easily gloss over long blurbs.

Instead of putting the blame on others’ lack of careful reading, one can proactively present acceptance criteria that are easy to read, straight to the point, and devoid of superfluous details.

3. Establish shared understanding

This is probably the most important characteristic and the one most taken for granted. If all the members of the team are not on the same page, then process and productivity become jeopardized. Having the development team review acceptance criteria before moving forward with the story minimizes confusion. Clarifications should be made about the criteria, and the criteria should be updated accordingly.

I’ve had experiences where all team members have been part of writing acceptance criteria. It allowed everyone to understand all parts of the story. It also provided opportunities for team members to chime in with questions and ideas. However, such a process might not always be ideal, especially for larger teams.

Nevertheless, it is important that each member can read the acceptance criteria. From there each member should gain an understanding of how to bring the story into completion. Regardless of whether it be in development or testing.

When too much is an issue

We’ve already explored the danger of unclear acceptance criteria. This results in the risk of introducing extraneous features into a story. However, the surprising opposite case can also exist: acceptance criteria may become too detailed.

“Acceptance Criteria should state intent, not a solution” (Segue Technologies)

Provide a blueprint of “what” (intention) instead of “how” (implementation). Otherwise, the development team may be robbed of the opportunity to explore different ways to solve the problem. On those lines, better implementations may be thought up after the initial thoughts on a solution.

Once you’ve written your acceptance criteria, you may ask yourself, “How many is too many?”
I’ve seen stories that range from zero acceptance criteria to more than fifteen (or at least it felt like that).

As a rule of thumb, I personally like to see three to eight acceptance criteria per story. However, towards the upper end of that limit, around five or more acceptance criteria, I would check manageability. I would carefully check to see that the story couldn’t be broken up into smaller, more manageable stories.

Others would disagree and argue that eight would already be too many. However, I like to lean towards providing as much “what” detail as I can without sacrificing conciseness.

Now what?

Ok, I lied. I did not provide an exhaustive list of acceptance criteria for writing acceptance criteria. The desired characteristics such as conciseness, clarity, and comprehension are subjective. I intended them to be.

I believe that there is no “correct” format to writing acceptance criteria. Their correctness is measured by the effectiveness in one’s team.

I highly recommend on initially using a template. They have provided many teams with a solid and safe structure that promotes good acceptance criteria writing. However, do not let that structure stop you from advancing into ideas that may promote efficiency and efficacy.

If you are a product owner or client writing acceptance criteria, I challenge you to ask your development team for feedback on the current acceptance criteria. With a bit of care, practice, and organization, crafting effective acceptance criteria becomes a powerful tool in improving the workflow of any team.

More to read

• https://rubygarage.org/blog/clear-acceptance-criteria-and-why-its-important — by Maryna Z. and Dmiriy G.
• https://www.leadingagile.com/2014/09/acceptance-criteria/ by Steve Povilaitis
• https://www.seguetech.com/what-characteristics-make-good-agile-acceptance-criteria/ by Segue Technologies
• http://agileforgrowth.com/blog/acceptance-criteria-checklist/ — by Kamlesh Ravlani