Get the Most out of Your Daily Scrum

Get the Most out of Your Daily Scrum

Hi, I'm Hans. I write a blog about Scrum, Agile and anything that might relate to it or could be interesting to people interfacing with the themes. If you aren't following me, then here is what you might have missed this month:

Don't Let Perfect be the Enemy of Good

Do Not Willfully Acquire Technical Debt!


It takes up 15 minutes of all our days, each day of the week. That's 75 minutes in a work week, amounting to 5 hours a sprint if you're doing 4-week sprints. You may not have realized it, but this makes the daily scrum the second most intense event on the scrum calendar, right after the Sprint Planning, which is time boxed at 8 hours four 4-week sprints. If you took 5 hours a month to just relax and be unproductive on the job, chances are your manager would like to have a word with you at some point. Yet when people call it a Daily Scrum, nobody will bat an eye, even if their version of it might not deliver anything valuable. Let’s dive into the specifics on how to get your money’s worth when conducting the Daily Scrum.


Don't do status meetings


There’s a reason the latest versions of the Scrum Guide do not include the famous three questions any more. In case you’re new to the party and have missed what I’m talking about, earlier versions of the Scrum Guide (Up until the 2017 version that I studied when doing my PSM I), while already pointing out that teams can come up with their own structure for the meeting, recommended that each member answers these three questions at the Daily Scrum:


? What did I do yesterday that helped the Development Team meet the Sprint Goal?

? What will I do today to help the Development Team meet the Sprint Goal?

? Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?


While there is still value in these questions and they are a great starting point for any fresh Scrum Team – in my mind at least – what sometimes happens is that these questions devolve into a more basic and way less valuable form. Let me know if this sounds familiar:


? What did I do yesterday?

? What will I do today?

? Any impediments?


This is the content of a status meeting for a manager that might worry about making sure his reports are busy bees that are well supplied with work. This is not something that will help generate insights and adaptions for a self-managing team trying to build the best product possible at any given moment. I’ve seen it happen personally, and I’ve read about it a lot online. This is a missed opportunity to inspect and adapt at best and a daily waste of everybody’s time at worst. See how the second set of questions completely ignore the Sprint Goal? The very thing the whole team agreed on being the most important and valuable next step for the product? That is what the Daily Scrum should focus on, what it should help achieve.


Make sure the team understands input and results


The Daily Scrum, along with all other Scrum events, have clear and understandable inputs and outcomes. I’ve realized that even long-standing professionals sometimes have trouble answering when I asked them what the inputs to a Daily Scrum or its expected results are. Before you read on, what inputs and results can you come up with straight from your dome piece?


The heart of a sprint is the Sprint Backlog. It represents the team’s current understanding of which steps to take to achieve the (hopefully) highly valuable sprint goal. It is the plan on how to succeed. As practitioners of Agile, however, you are probably familiar with what they say about plans. I like to look at and quote from the military and war, because people have come up with a lot of agile principles and methods when their lives or the lives of their soldiers depended on it. A famous quote from Helmuth von Moltke, a Prussian military commander, goes like this: “No plan of operations reaches with any certainty beyond the first encounter with the enemy’s main force.” Often, it’s misquoted as “No plan survives contact with the enemy.” And in Scrum, our enemy is the tasks we have pulled into our Sprint Backlog. What does contact with the enemy look like?


When starting work on product backlog items in the Sprint Backlog, you will soon realize that there are some things that have not been accounted for or behave differently than expected. You may find that a task will take way longer than anticipated, you may find that something is way easier than expected, or you may even find out that an item cannot be completed in the way you drew up. This information, which the team gathers on a daily basis, forms the first and most important input to the Daily Scrum. The other inputs are your current plan in the shape of the Sprint Backlog, and the overarching objective of the Sprint: The Sprint Goal.


Armed with these three bundles of information, your team should reflect on the current state of the plan and adapt it. It’s not important that each member answers the three questions, but it’s important that you adapt your plan. That is the result you are looking for: An updated Sprint Backlog. If you just left your Daily Scrum and your Sprint Backlog has not changed, then chances are you have done it wrong. You have probably missed an opportunity to inspect and adapt, the core of empiricism. And if that happens a lot, you need to strife to get more out of your 15 minutes of Daily Scrum each day.


Inspect and adapt


Now that we know what we are trying to achieve by meeting up daily, let’s focus on how we can achieve it. The easiest way to get going with this is with something we do way earlier, at the Sprint Planning. When we all agreed on a Sprint Goal and which items we can do this sprint to achieve it, the next thing we do is decomposition. In this step, we translate these valuable product backlog items into a set of tasks we will complete for them to meet the Definition of Done. The Scrum Guide is oddly specific in that regard, it recommends that these smaller, decomposed work items should be doable in one day or less. This is a very important and easily overlooked detail which will empower your Daily Scrum to truly shine.


By having a Sprint Backlog filled with tasks that are doable in a day or less (or at least the team thought they were when coming up with them in the planning), you will guarantee that your plan changes daily. Each day you inspect the Sprint Backlog, you should see items moved into “In Progress” and items landing in the “Done” bucket. Gone are the days of “Yesterday I worked on this, today I’m gonna continue working on this, no impediments”! If a task is being worked on but has not moved since yesterday, then you already have identified that an impediment is present. Is the task more difficult or more work than anticipated? Decompose the task further. Is the task unachievable? Find a different way to finish the PBI. Is the task unnecessary? Delete it then and there. Do this and you will find that your plan will adapt to the findings of your development team naturally (provided your Daily Scrum is conducted in an open and respectful environment where the team members can speak freely without fear of blame).


Once you’ve taken a look at state of the individual items, you may find that they have repercussions for other items in the backlog. Try to update these items on the spot if you can, or work with your team on uncovering the necessary information after the Daily to make sure your plan is up to speed. If you conduct your Daily Scrum like this, you will see that these 15 minutes a day will be quite busy!


Takeaway


Do not just sit there and talk about what you have been doing and are going to do. As members of agile teams around the world we have to make sure we stay self-managing and we cannot let our Daily Scrums devolve into worthless status meetings. Inspect and adapt. Engage the tasks, gather your findings and change your plan. Your life may not depend on it, but your Sprint Goal, and ultimately your product, does.


Abhijeet Kumar Barla

Data.Development. AWS. Python

1 年

Very well written.

回复

要查看或添加评论,请登录

Hans Martin Steinbacher的更多文章

  • How to Achieve Your PSPO I Certification in Self Study

    How to Achieve Your PSPO I Certification in Self Study

    ?? Hi, I'm Hans. I write about Scrum, Agile and anything that might relate to it or could be interesting to people…

    2 条评论
  • Product Backlog as a Suggestion Box

    Product Backlog as a Suggestion Box

    Hi, I'm Hans. I write a blog about Scrum, Agile and anything that might relate to it or could be interesting to people…

    4 条评论
  • Three Ways How Scrum Unravels Complexity

    Three Ways How Scrum Unravels Complexity

    Hi, I'm Hans. I write a blog about Scrum, Agile and anything that might relate to it or could be interesting to people…

    1 条评论
  • Overproduction in Software Development

    Overproduction in Software Development

    All agile teams pride themselves with short feedback loops and close customer collaboration, delivering exactly what…

    5 条评论
  • The Cult of Done Manifesto

    The Cult of Done Manifesto

    Hi, I'm Hans. I write a blog about Scrum, Agile and anything that might relate to it or could be interesting to people…

    4 条评论
  • Is Continuous Integration & Deployment Non-Optional?

    Is Continuous Integration & Deployment Non-Optional?

    Hi, I'm Hans. I write a blog about Scrum, Agile and anything that might relate to it or could be interesting to people…

    1 条评论
  • Cyberpunk 2077: The Agile Redemption Arc

    Cyberpunk 2077: The Agile Redemption Arc

    Hi, I'm Hans. I write a blog about Scrum, Agile and anything that might relate to it or could be interesting to people…

    4 条评论
  • Show your Sprint Backlog to the World!

    Show your Sprint Backlog to the World!

    Hi, I'm Hans. I write a blog about Scrum, Agile and anything that might relate to it or could be interesting to people…

    2 条评论
  • The Difference Between Screwing Around and Science in Scrum

    The Difference Between Screwing Around and Science in Scrum

    Hi, I'm Hans. I write a blog about Scrum, Agile and anything that might relate to it or could be interesting to people…

    4 条评论
  • Don’t Let Perfect be the Enemy of Good

    Don’t Let Perfect be the Enemy of Good

    Last week I wrote about technical debt and how we should not compromise on quality when delivering increments in our…

    2 条评论

社区洞察

其他会员也浏览了