Welcome to the Home of Scrum! ™

Every company has customer focus in its vision or mission statement, but is it really? As an employee of a development team, how do I know if this is the case? How do I know we are are customer obsessed company? How do I sense it? These are the questions we want to explore in this post. Let's start with a simple question for the team: How many people are between the user and the development team? Typically, you see something like this: Often there are project managers, business analysts, requirements engineers, deputies, steering committees, usability experts, testers, or QA teams between the team and the user. I see the user(s) as our most important customer, because if the user is not happy, no one will pay for the product (sponsor), nor will any other market participant be interested in it. What can the Product Owner do to improve this situation? I have collected 6 tips for this: 1. Invite the User Instead of focusing on the perfect requirements and investing an extreme amount of time there, I would recommend bringing the user closer to the team. Do we ever want to invite a user to the sprint review? Or to the team room and show how we work and ask him for feedback on the current feature? What can I do to detach myself as a Product Owner even more from this system and focus more on the product strategy instead? 2. Merge Teams instead of splitting them up Instead of splitting teams into specialized silos, such as a test team or a QA team, which then pass on work to be able to develop more "productively" themselves, I would recommend bringing teams together. Too often I have seen "bug ping pong" between teams and never found it to be efficient. I would strongly recommend bringing teams together, pairing or mobbing or ensemble programming and completing and finishing (Definition of Done) features (Product Backlog Items) together. Read the blog "5 practices that help with agile software development" for more information. 3. Introduce Feedback Moments Instead of accepting or "rejecting" Product Backlog Items, I would recommend as a Product Owner to look for a different way of collaboration. For example, "feedback moments" go in this direction, which allow to bring the user directly to the team and let them give feedback. Feedback moments can empower the team, to whatever they need and confront them with the user problems instead of delivering pre-chewed solutions. This also helps with motivation. PS: Accepting or rejecting also implies a hierarchy, which we don't want to have in a Scrum team. So call it feedback moments. 4. Celebrate added Value instead of busy KPIs Instead of celebrating Velocity, Utilization and "Feature Completeness", we should define success as Impact for the user. What in the user's world is made better by our product? How does the team get more empathy for the user? More ideas on this in this Twitter stream from me. 5. Break down large features into smaller goals and bites Instead of working through big features (large batches) over multiple sprints, I would recommend working in small steps. How can we break down the big product vision into actionable sprint goals? Into daily goals that we can celebrate and measure as a team? It's counterintuitive to work in small batches, but progress and discipline bring faster successes and allow the product to become deliverable faster. 6. Delegate Sprint Goals Instead of doing everything myself, I think about what I can delegate as a product owner. Can I delegate the entire sprint goal to a department? Thought example: "For the next 2 sprints we are working on features for the internal marketing department. Please talk directly to Stefan from the department and just keep me updated. I will always be present at the Daily Scrum." In other words, I delegate the responsibility about the content of the product to another person and just get more information for decisions when I need it. Alright... 6 experiments to try and let me know of 😀. Could you stay quiet as a product owner and let the team run on its own for the next two sprints? Why not? How far away is the customer from the team?

Check your Scrum knowledge and with a little bit of luck, win an autographed book, stickers and posters. This week is all about team spirit, collaboration and self-management. Have fun and good luck.

One of the things you do as a Scrum Master is help your Product Owner in different aspects of their role. It doesn’t mean that you need to know how to do their job yourself, but you should be able to bring valuable practices and techniques to their attention. One of the constant struggles is, of course, effective Product Backlog management. I’ve seen teams with empty backlogs. I’ve seen teams with 300+ items in their backlog. And most often, I’ve seen teams with everything on their backlog marked as “Highest priority”. Sounds familiar? Unfortunately, it often is. Product Backlog is as good as its order Focus is one of the five Scrum Values and a very important one, because without focus you can’t succeed. Without focus you might be doing a lot of busy work and still not deliver any value to your customers and stakeholders. And in an Agile environment, that is the worst that can happen. Why? Because you waste your team’s time and your organization’s money, while not inspecting and adapting and reducing overall transparency of the work at hand. You role as a Scrum Master is to help everyone understand how to implement the value of focus in their work. This doesn’t only apply to the Scrum Team, but to the organization as a whole, including the stakeholders. Focus is translated into clear order of the Product Backlog and you should help your Product Owner if they are struggling. Order versus priority An important point I’d like to highlight is that focus is shown through a clear order, not a clear priority. What’s the difference? Priority has been misused in an organizational context. Priority is often related to what is the most urgent or who has the loudest voice. In addition, priority is usually divided into a few categories: high, medium, low (or sometimes more). Which means that we always end up with multiple things that at high priority (P0 as it was used to be called in one organization I worked for). So, what is the first priority out of all those high priorities? The usual answer: “they all are important”. That is NOT how we can focus on the most valuable work. That is why instead we are talking about the ORDER of the Product Backlog instead. The order will put everything in the list into a sequence: one, two, three, four, and so on. It means there is only ONE number ONE which brings focus back into the work of the Scrum team. Everything is important This reminds me of a dialogue from one of my favourite animation movies “The Incredibles”: - Everyone is special, Dash. - Which is another way of saying that no one is. A lot of items on our list are important. But if we can’t separate them into an order, it’s like saying that none of the items are important. When we are ordering them in a clear sequence, we are not saying that number two, or three, or lower, are not important. Instead, we are saying that number two is less important in comparison to number one (it’s just like relative estimation!). However, because stakeholders and customers (and maybe even your Product Owner) were never forced to order things with a clear number one, two, and three, this exercise can be very challenging. How do we choose? Where do we even start? There are a few simple tools you can use as a Scrum Master to help you out. Simple tools for Product Backlog prioritization There are many ways of how you can facilitate the ordering process with your Product Owner and stakeholders. Here are a few things that I personally often use: Only one thing This is not an actual tool, but just a simple question you can ask when people have trouble choosing between two or more items. Just ask “If we are out of time and money, what would be the one and only thing you would want get done for sure?” MoSCoW This is an extremely easy technique that you can use during Product Backlog creation, story mapping, or release planning. Or when you need to order a long list of items. Label every item in the list as a “must-have”, “should-have”, “could-have” or “won’t-have”. Only one label is allowed per item. That way you can easily shorten your list and proceed with further ordering. I describe this technique in more detail in my facilitation guide “Product Backlog creation workshop”. Relative Value Estimation Another way of figuring out the order of items in the Product Backlog is using tools like Planning Poker, that you would use for estimating effort in Sprint Planning or Backlog Refinement, and instead use it for value. Do it exactly the same way but for estimating how valuable each item is in comparison to other items. If you are new to relative estimation, I have a great facilitation guide on this topic called “Relative Estimation for Agile Teams”. Check it out for more information. 20/20 Vision This is a fun technique that can prove to be extremely useful when you have a lot of stakeholders who can’t agree on the order of items in the Product Backlog. Take the list of items you have and draw a line above it. You can easily facilitate it in a virtual setting or in-person with various tools. Tell the participants that they can put only 20 items above the line – these will be the most important. Let them disagree, debate for their items, but ultimately come to an agreement as a group. Then draw a line above those 20 items and tell the participants that they can only put 10 most important items above it. Then do the say with 5 items, and to finish with 1. In the end the group will have an order they all have agreed on (after a long heated debate, most likely). As a Scrum Master you have an important role to play in bringing focus on value to your organization, helping them inspect and adapt, and more importantly, create transparency around the work of the Scrum team.

When we introduce Scrum to some companies, sometimes the question arises - "Why are there so many meetings in Scrum? When do you do 'real work'?" I've been answering this question verbally for so many years, I thought it was time to write a blog. So here's my answer - don't use Scrum! It has too many darned meetings. Try this instead for the next 3 months. It won't cost you a dime in training, coaching, consulting, tools, whatchamacallit... At the start of each work week... Take a print out of your calendar for the current week Make a list of all the meetings Total up all the durations of the meeting At the end of each work week... Take a print out of your calendar for the week that just got over Make a list of all the meetings Total up all the durations of the meeting Were there other meetings that did not show up on the calendar? Great! Add them to the list and the total durations. Compare the print-outs of the meeting calendar at the start of the week and the end of the week. What can you learn? For instance, how did this list of meetings that actually happened by the end of the week compare to the meetings you expected at the start of the work week? At the end of each work week, fill out this self-assessment Total # of minutes spent in planned meetings Total # of minutes spent in un-planned meetings On a scaled of 0 to 10, how effective was your team in making progress towards your team goal? What the heck was the team goal, anyway? On a scaled of 0 to 10, how effective was your team in maximizing sustainable, measurable value? On a scaled of 0 to 10, how effective was your team in minimizing time spent on meetings? On a scaled of 0 to 10, how effective was your team in maximizing time spent on doing 'real work'? Plot the survey results as trend lines At the end of 3 months... Look back at all the print-outs of before and after weekly calendars, look at all the meetings you had, and draw out your team process on one single page Name all the meetings, the intent of the meetings, participants, durations Try to explain this to an unsuspecting guinea pig. Don't forget to show them the self-assessment. trend lines. Now ask them to explain it back to you. Now, tell them to look at the Scrum Guide and have them explain Scrum to you. How did they react? What questions did they ask? What made sense? What didn't? What did you learn from the interaction? Now, compare / contrast your process to Scrum and answer these questions... Which of these has more meetings? Which of these has more real work? Which of these might be most effective in making progress towards your team goal? Which of these might be most effective in maximizing sustainable, measurable value? My life coach - Joy Perkins often reminded me that the quality of life is determined by the quality of questions we ask. Learn to ask the right question. What is the reason for your team's existence? Minimize meetings? Scrum might not be for you. Maximize real work? Scrum might not be for you. Make regular progress towards your team goal? Scrum might be for you. Maximize sustainable, measurable value? Scrum might be for you. My wish for you is not that you read this blog and get convinced Scrum is right for you. Just that you shift from asking questions that are irrelevant to your team's existence to questions that are more meaningful to your team's existence. Good luck!