Stephan van Rooden
co-founder of Entrepreneurability
- To enable entrepreneurial abilities (taking initiative, making strategic and business decisions, innovate and bear the risk)
- To bring to life ideas, talents and skills in an economy driven by purpose.
Courses taught by Stephan
Upcoming Classes by StephanSee all upcoming classes
Classes Attended by Stephan
Stephan has no visible classes.
Latest Blogs by StephanSee all blogs
Stephan van Rooden
Imagine this, you are at the weekly company meeting in a room of 60 people. All of them are co-workers who you have been working with for several years. You feel engaged and committed to the goal set by your company.
Jun 25, 2018 Read blog
Stephan van Rooden
When is a Scrum Team successful? Which criteria do you use to determine if a Scrum Team is doing a great job? From my point of view a Scrum Team is doing a great job if they deliver an increment with the highest valued features, with the best possible quality and they continuously strive for improvement. In this post, I will share my thoughts on a discussion I had with a Scrum Master recently on partnerships. I will not provide practical examples, if you are interested, take a look at Evidence Based Management and read this. The discussion started with the following question: Changing the Contract “Stephan, how do we, Scrum Master and Development Team who are hired by our client, Product Owner, change the KPI’s (Key Performance Indicators) in our contract to measure if we are doing a good job?” Without hesitation I replied something related to the statement I made above. However, the Scrum Master did not accept my answer. He said: Listen, in our current contract we get rewarded for every time we are within our initially estimated delivery schedule and if we stay within our budget. "How do we know, now we started using the Scrum Framework, we have done a good job?" Then I explained that by deciding as customer and supplier to start using Scrum, a lot more has changed then just doing some events and incrementally develop our solutions. Making this decision you have mutually agreed to move from a demand-driven approach a.k.a. doing projects. To a supply driven approach, delivering solutions. And by using Scrum, the Scrum team has a shared responsibility to deliver the best and most valuable solution to the customer. With this decision you both have committed to this goal, you both have a stake in the success of the things you do. You now are a Scrum Team and yes, each role has a different angle on how to approach this shared responsibility but you are in this together now. In this together The Scrum Master looked puzzled and replied: "But we are a pay-by-the-hour company! We just deliver highly qualified people, we cannot be held responsible for the value we deliver to the users? What kind of KPI’s do we need?" Yes, you deliver skilled people who bring in their experience and expertise to create a valuable solution. But to build the right things in the right quality in the right way they need to interact with the Product Owner (and Stakeholders) to figure out how to build the right thing? You need each other...right? "Yes!" You, as a Scrum team, can only be successful if you collaborate. So you need to figure out together if the thing the Product Owners wants is more valuable than the cost of the team. The client buys capacity from you as a supplier per sprint in the form of a Development Team. So as long as the benefits of the items delivered in a sprint exceed the costs you are on the right track. Send it back to the kitchen! I always compare a Development Team to the chefs in a top restaurant. They need the proper equipment to cook but how do you judge their performance? If the food tastes good. If it doesn’t I do not blame the waiter, I sent it back to the kitchen! The development team is responsible for delivering a high quality product.As a restaurant we are all together responsible for delivering a great experience with great food. "Quality is something we are responsible for?" Yes! Put that in your contract! But wouldn't it be great of you could create a contract that reflects the responsibilities of the entire Scrum Team? "Now you are being naive! That is never going to happen?" Why not? As long as you are only being judged by the quality delivered why should you care if it adds any value? Why do you do this job? To deliver high quality stuff that nobody ever uses? Or do you want to create something valuable that people like to use and is of good quality? And yes, that is a rhetorical question. Partnership I see a lot of client/supplier relationships using Scrum. When signing the contract they both say they engage in a partnership. But the agreements they make usually have nothing to do with being partners. A contract hardly reflects the image that we need each other to be successful and that we both care about the goal we try to achieve, if that is the case there is no shame in making money for both partners. That is why Scrum says nothing about having KPI’s between a Product Owner and Development Team since using Scrum implies a partnership where we all contribute to achieving the same goal. Soon I will elaborate more on partnerships and how I make my decisions when I am looking collaborations.
Apr 3, 2017 Read blog
Stephan van Rooden
The Daily Scrum, or most of the time referred to as the "stand up." Probably the most well-known event when we talk about Scrum. An event that lasts no longer than 15 minutes and where the Development Team inspects the plan for the sprint and see whether this plan is still valid. That is it! Nothing more, nothing less. Nevertheless, there many thing that go wrong during this 15-minute event. In this post you’ll find, the most common problems during a Daily Scrum and how to solve this. The 'status update' consultation This is, unfortunately, the number one issue in most of the teams! Often it is the (project) manager, Product Owner or Scrum Master, to whom the team answers what the team has been doing and what they are going to do the upcoming day. Strange! Especially for these roles, because none of whom have an active role during a Daily Scrum. The purpose of the Daily Scrum is for the Development Team to inspect jointly whether the plan they have made in the Sprint planning is still valid. By sharing relevant information that may be of impact to the schedule the team determines the need to adjust their plan. It is up to the ScrumMaster to learn the Development Team how to do this. If there should be re-planned, only then it is useful to involve Product Owner in the discussion (in the case the scope is affected). These are some of the causes of this behaviour. 3 questions To get the information shared, many teams use the following three questions: 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? The purpose of these three questions is to share the information that is relevant to inspect the sprint backlog and validate whether we as a team are still on the right track. Nothing more, nothing less. These three questions are not mandatory and what I often see after everyone has answered these three questions, is the team ends the Daily Scrum. But then you're not done yet! In fact, has just started! Now you have shared the information on which you can see, as a team, if you have to adjust. It is not about answering the three questions. It's what you do with the information shared! If there is nothing special to report, and it all goes smoothly then a Daily Scrum is done in just a few minutes! The Scrum Master that works too hard If as a Scrum Master you do your job well, you have not much to do. However, Scrum Master prove are not properly trained are very busy. During the Daily Scrum you as ScrumMaster have no active role. So, if you as a Scrum Master acts as moderator, the who’s-turn-is -it-to-speak-now-coordinator and tickets mover. Then, you are not doing a good job! People can organize those things themselves. As a Scrum Master you have to teach the team to understand the purpose of the Daily Scrum (inspect if rescheduling is necessary) and how they can do this no more than 15 minutes. Hardworking Scrum Masters are often cause more problems some of which pass in this post. So, Scrum Master, grab a cup of coffee and let the team organize themselves in these 15 minutes. So you have your hands free and you can keep busy with those things that are said (or not said!). Unanswered requests for help When a team is suffering from an overactive Scrum Master, questions with the (unspoken) request for help is most overlooked by both the Scrum Master and the Development Team. A small example of what I have experienced recently during a Daily Scrum when a new team member was speaking. This is what happened: Team member: "Today I want to work on this task (points to task), but I'm not sure how to approach it." Rest of the team, including the Scrum Master: "..." Team member: "I immersed myself in the subject but I doubt about whether this is the right approach." Rest of the team, including the Scrum Master "................" Team member: "It would be nice if someone could look at this with me." Rest of the team, including the Scrum Master "........................." Then the Scrum Master "That was it? Okay, next, eh Pete you? " At that point I confronted the team with what happened. Someone asks three times a request for help. It wasn’t formulated a question but it is indeed a request for help and no one responded. This was a hard lesson for the team, that does not help one another and the Scrum Master who was too busy to manage the 15 minutes to hang notes instead of listening what happened here. This is where a Scrum Master focus should be and what a Scrum Master must teach the team to recognize themselves. Lack of transparency Many teams use a physical board but what is often missing is inspecting the burn down chart. A practice which helps the team to monitor how much work is remaining and how the team is progressing to finish their work. Teams that use a tool like JIRA or TFS have this functionality at their disposal, but this is rarely inspected. What these teams often do, in addition to treating only 3 questions for the status update. is to individually inspect work instead of the feature that the team is trying to deliver. Both JIRA and TFS have filters that can sort a Sprint Backlog per team member and the tasks this person is planned to work on. If the team loses focus on finishing features and one is mainly concerned with optimal use of the available capacity, please watch this short movie. This also means less interesting discussions during a Daily Scrum. Because they are concerned with individual focus. Also it is easier for the team not to be transparent about the work you contribute to the Sprint Goal. Again, it is up to the ScrumMaster to confront the team with this behavior. By simply adapting the way we present information in such a way to provoke a different discussion. Day off/ Working from home Finally, the situation that a colleague has a day off or works from home. This often creates unnecessary problems in a team. Let me first state: working part-time or working from home is possible when working in a Scrum Team. However, a team must makes agreements on how to deal with it. I regularly see teams during a Daily Scrum that find out that the colleague has a day off. Or he/she works at home without sharing this information. Then they try to figure out how far the colleague has progressed and two colleagues need this work to continue. Incomprehensible that a team does not know how to overcome this while the solution is simple. Situation 1: Colleagues works from home. Great, so they probably call in using Skype or just by phone. Thus, there is still information to be shared and to move tasks on their Scrum board can probably be done by someone else from the team. Situation 2: Colleagues has a day off. The team in such a case, determine together that in case someone has a day off does not pick up a crucial task without being sure that it can be completed. Or colleague makes sure that at the end of the day, at least one person from the team knows what has been done. In this way, the information is always known in the team and the colleague does not have to be disturbed during the day. This has nothing to do with the role of ScrumMaster or good use of Scrum. This is just purely being a professional! A long post about a seemingly simple and quick event when working with Scrum. Do you recognize this struggle? Of do you want to avoid such situations before you are going to start with Scrum? Then the Professional Scrum Master training is a must! Please subscribe now!
Oct 24, 2016 Read blog
Stephan van Rooden
This summer, during the Olympics, the Euro Soccer Championships and the Tour the France, while cheering in front of the tv, I noticed something in the way teams perform. And it worried me. Even more because I see the same thing happening in organizations. Why did the English soccer team fail against Iceland? How come the Dutch field hockey team didn’t win a medal? And what does this have anything to do with Agile Coaches? In this post, I will explain what to look for in an Agile Coach and why not to hire them full-time. A system or framework will not make you a winner! Everybody has heard about it, many you have seen it. The Icelandic team beat the English soccer team. Were they better soccer players? No, they were not, and they knew that. However, they did operate as a team and were not bounded by an elaborate and complicated system. The systems and plays are taking over the creativity and craftsmanship of any team. When things turn sour, many teams that rely on a system are unable to break away from it. They have been brainwashed and probably punished by the coach not to break away from the system. Take a look at this scene from Dutch professional basketball coach, Ton Boot. During practice they have a limited amount of passes to get to the other side of the field and score. Everybody needs to have touched the ball and the amount of passes leaves no room for error. Listen to what he says when they fail! [embed]https://www.youtube.com/watch?v=vdtEw_4byPg[/embed] Why do they do this exercise? This has nothing to do with using a certain offensive play. It has to do with the ability to operate as a unit and dealing with the situation (which is always different). How do you, or your Agile Coach, deal with the Scrum Framework? Do you treat is as a system? Just an implementation of some rules and followed up by punishing any deviation from these rules? This works fine up to a certain point! As soon as you run into problems or your organization is under great pressure to deliver, people need to be able break away from these rules. Teams need to understand the values beneath the rules to get things done. The ability to let go of the rules and teaching teams to act from values is important for an Agile coach to understand and act upon. Deal with Super Chickens! In a highly competitive and complex environment we can no longer rely on a single superhero. One person cannot carry the entire team. You need a great balance in a team. Why? Take a look at this interesting TED talk by Margaret Heffernan: [embed]https://youtu.be/Vyn_xLrtZaY[/embed] So, what do you do as an Agile Coach when you run into a Super Chicken? Again, Ton Boot is showing a great example of on boarding a new team member, a Super Chicken. [embed]https://www.youtube.com/watch?v=UjQfhpNzvT0[/embed] (Some parts are in Dutch but I am assuming you’ll get the point) What would you do in this situation? We all have been in such a situation throughout our professional life but how often have we dealt with it? Most organizations are too afraid to face this super chicken since they are too happy they finally have a talented superstar. But if you do not have this super chicken put his interests in line with that of your company they will destroy your company. An Agile coach should be able to identify super chickens and be able to confront them with their behavior (or even better, teach others how to do this). Need some inspiration? Read these books ‘ 5 dysfunctions of a team’ and ‘ The Phoenix Project’ A coach should not be in the spotlight I truly believe in this statement. A coach should not be the most famous person of the team. If this is the case, something is probably wrong. A great coach should not have to teach players or individuals on how to do their job. They know how to hit a ball or how to write code. Otherwise you need a trainer. A coach teaches people to work together, to give feedback to each other and to operate as a unit. In my training courses, I often use the movie below. I love it, it shows the behavior I expect from Scrum Masters and Agile Coaches. [embed]https://www.youtube.com/watch?v=3Tv2iHlMhmM[/embed] As a coach you teach people to work together, to think for themselves and from time to time ‘punish’ bad behavior. Don't hire an Agile Coach full-time! Being an Agile Coach is not a full-time assignment! Whenever, I get requests to help an organization as Agile Coach, I never take a full-time job. I don’t see the added value and neither should you! Being an Agile Coach comes with a great risk of overdoing your job. You are hired to make the organization more Agile so you will probably try to coach the sh*t out of the teams. Literally! However, you don’t have to intervene continuously to make an organization improve continuously. As a child my parents had this nice fireplace in the middle of the room with a cast iron chimney. As a kid I was drawn to the fire and wobbling towards to fireplace to put my hand on the chimney. My parents prevented it every time (thankfully). However, I did not seem to learn from it, so one day they decided, when the fire already was out and the chimney wasn’t that hot anymore to just let it happen. It hurt, but I wasn’t injured but I never ever again walked toward the fireplace ever again! So sometimes you need to step away, not be there to maximize the impact of learning. For how long do you need to employ a coach? On average this is around three years for a sports coach. Ton Boot works for 3 years with a team followed by a sabbatical year to recover, improve and learn. The Agile coach also has an expiration date. From my experience, the effect of a single takes wears out after 6 months. After this the assignments needs to change significantly or the agile coach will have to move on. Yes, there are exceptions, even in sports as there are in Agile Coaching but like I already said, these are exceptions. So what to look for in an Agile Coach? A person who: Knows the systems but does not cling to it Knows how to identify and deal with Super Chickens Understands you do not want to hire them for more than 3 days a week for the next 6 months Want to know more or do you share a different opinion please comment.
Sep 14, 2016 Read blog
Stephan van Rooden
What really makes a transformation of your organization successful? Which elements should be in place? Which complicated framework for scaling agile should I choose? I tend to feel disappointed when trying to think of the number of organizations which actually succeeded in such a transformation. We, the Dutch, should be absolute rock stars when it comes to scaling agility given our rich nautical heritage. Let me explain. Oil tanker In the past couple of years I have heard the following statement a lot:” We want our organization to transform from a big oil tanker to a fleet of small sailing boats.” And yes, that would indeed be a nice metaphor when attempting to describe a typical large-scale introduction of Agility. These statements are always made by management teams. Let me be clear, there is nothing wrong with this statement, I like it actually quite a bit. But I could never think of a clear recipe for making it work. While contemplating about this my thoughts brought me back to one of the best summers of my life. And there might lie some insights. Sailing Camp When I was in high school we went sailing for a week during our summer holiday. This camp was a self-sustaining camp, we cooked our own meals, had a schedule for cleaning and we trained our own ‘skippers’. At the end of the week we closed off by demonstrating our skills with a parade called ‘Admiraalzeilen’ which can best be described as synchronized sailing. This parade works as follows. All boats sail equally fast, make the same manoeuvre at the same time, all under the direction of one skipper called the ‘ admiral’. It looks something like this: [embed]https://youtu.be/kcZhKyv1fGg[/embed] As you might imagine this is extremely difficult to master and has some prerequisites to make it work. First, let’s dive a little into the history. Admiraalzeilen Already in the 12th century merchant boats have used this technique to better withstand attacks from pirates or warships. In the 17th century, ‘ Admiraalzeilen’ became an extremely popular in transportation and warfare. Because of ‘ technological’ innovation, boats became larger, heavier and received more firepower. This made strategic maneuvering more complex, but to outmaneuver the enemy this became necessary. The ability to be able to manoeuvre fast and flexible led to a new way of controlling the fleet, called ‘ Admiraalzeilen.’ A fleet would be divided into smaller squadron with boats of the same type. This would make sure that differences in speed would prevent a squadron from breaking up. Each squadron was appointed an admiral, typically the first boat, which would decide the course and the maneuvers to be taken. Even today, large aircraft carriers, operate in a way with seem similar to this approach. How to successfully S(c)ail Each boat needs to be roughly the same size and type In order to make this work the entire squadron needs to be the same size and probably the same type. If you create a squadron consisting of one large boat and multiple smaller ones. Making a turn at the same time is impossible. Try turning around 180 a smart and a limousine at the same time, they will never be done at the same time and will definitely not be in the same place. Also controlling the speed of different boats is difficult, even if you have the same type of boats speeds differ but the difference would be controllable. So looking into your own team, please make sure they are roughly the same size and operate in the same value chain. This would make maneuvering and managing speed more easy. Each boat needs to know how to sail Obviously, having a squadron with an Admiral being the only one who knows how to sail will never work. So training is of the essence here. This is why Scrum is a great way to teach people how to ‘sail’. It is the common language that everyone understands like in sailing. Everybody on a boat should know what ‘Starboard’ means, what a ‘ Mainsail’ or ‘Jib’ is etc. For a small boat it’s easier to learn, imagine if you want everybody to know how a frigate works. Good luck! Each squadron needs an admiral Each boat has a captain (product owner) deciding on the direction. But a squadron needs an Admiral, responsible for deciding the direction of the squadron, come up with a strategic battle plan. A responsible job since the Admiral needs to take into account the capabilities of the Squadron, the surroundings of each boats etc. When does it fail? Change course at the time As you can see in the movie above the boats manoeuvre slowly, it takes time to execute a change of direction, it will slow the boats down. If you change direction too often each boat will end up just floating and no boat has any control anymore leaving them vulnerable to the tide of wind. And when these elements take control of your squadron you will end up stranded or on the bottom of the ocean. Maneuvering should be thought of carefully and after each maneuver boats needs time to regain their velocity. Ignoring the environment of the entire squadron Nothing is more frustrating that having an Admiral deciding on a manure that is only considered to work for the first (few) boats. During our sailing camp we numerously ended with a couple of boats in shallow water because the admiral forgot that making a turn will not have the boats end up in the same position, but each in a different position. That is also why you needs skippers on a boat to keep thinking for themselves. In such cases it would be better to break away from the line then to ‘lose’ a boat. Expecting it to work at the first try This one is too obvious but I see it go wrong many times. You will fail, a lot! So can have meetings until you drop but you only learn when you actually start doing it. As long as you make sure everybody knows how to sail you will be fine. I see organizations create comprehensive Powerpoint presentation. Being the result of a trillion meetings with expensive people to get it right the first time. Yes, there are tricks! There are good practices! But you should only apply them if you need them. having 15 boats do the same manoeuvre at the same time is difficult enough. Why bother them with all kinds of scenarios that will never become a real life situation. The wind, tides, currents and even people are different and act different every time! Are we Scaled Agile rock stars? No, we are not, apart from our nautical heritage, we, the Dutch are also famous for something else. ' Polderen', we tend to lose ourselves in trying to have everybody involved in agreement with the direction we are going. So we end up in countless meetings where we talk a lot but hardly every decide. That is the primary reason we, the Dutch, are still struggling with scaling Agile. But we do have to potential to be rock stars! Check out Nexus and find out it's impressive that a technique already proven in the 12th century still works!
Jul 28, 2016 Read blog
Stephan van Rooden
This week, co-creators of Scrum, Ken Schwaber and Jeff Sutherland, released a new version of the Scrum Guide. At first glance, just a small paragraph on Scrum Values is added. But this addition may offer a larger impact and be an extremely useful addition for Scrum Masters. So, today during the first day of my Professional Scrum Master Training, I shared this new addition to the guide with the students. Their first response while shrugging: So what? Their second response, how is this different from the Agile values? And then they paused. This gave me the opportunity to elaborate briefly on what these values mean: Commitment - Being committed to the team and the sprint goal. So when you finished your work so check if you can help someone else in the team to help them meet the sprint goal. Focus - Eyes on the goal and not being distracted by personal favors, not even for the CEO, if it endangers the sprint goal. Openness - Being transparent on how the team is doing and being open about failure or difficulties you might run into. Respect - Sharing your knowledge within the team and embracing the professionalism from your team members. Courage - Being a professional to admit mistakes and move beyond your ego to change direction to solve complex problems. more on Scrum Values read this blog by Gunther Verheyen This resulted in an enthusiastic reaction from the group. So, the Scrum Values, in fact describe the desired behaviour of a Scrum Team? Yes, yes, YES! The new Scrum guide provides Scrum Teams some key elements of desired behaviour. This will help them to move from doing 'Mechanical Scrum'* to 'Professional Scrum'. This insight gave the students a boost of energy and looking forward to the second day of training to dive into the behaviour of a Scrum Team and how the Scrum Master can facilitate the team in showing this behaviour. Download the new Scrum Guide! *(just following the rules, and not understanding why you do things)
Jul 9, 2016 Read blog
Stephan van Rooden
How to facilitate a Product Backlog Refinement meeting? What do you do as a Scrum Master to keep the item under refinement on track? When do you estimate and what do you do when you need more time for discussion? In this third post of this series on Product Backlog refinement you will find some good practices on how to facilitate an effective and efficient refinement meeting. This series consists of three posts: Before you bring an item into a meeting What do you typically do during a meeting focusing on refinement? Facilitating a meeting on Product Backlog refinement All the theory from the earlier posts on Product Backlog Refinement are very nice and understanding the goal and the mechanisms at play during this activity might be very useful. Most questions, I get from Scrum Masters is how to keep a meeting on track. Below you can find a graphical representation of what steps you take and which decisions you make during a refinement meeting. Needles to say, is that there should be not meeting held if the Product Owner has nothing to be refined. Once gathered it never hurts to repeat why we have an activity called Product Backlog refinement so everyone involved is reminded of the value of this meeting. First action to take when starting to refine a product backlog item is to have a time-box of 10 minutes to discuss the product backlog item. After those 10 minutes you are reminded to reflect on the next step to take. Making this a working agreement for Product Backlog refinement is a great way to embed this in the Scrum Team.In those ten minutes the Product Owner starts with explaining ‘what’ the product backlog items requires. What is the problem or wish a customer needs a solution for? Followed by ‘Why’ this item has any value for a customer/user and for the Scrum Team’s vision. If the Product Owner is unable to explain this to the Development Team the Product Owner has some homework to do. It does not make sense to continue refinement on this item and the time will move back to the product backlog. If there is time left for a new item to be discussed, the Product Owner decides which item to discuss next. When this item under refinement is clear and the team has an idea how to create it. The team can estimate the item. It doesn’t matter if the item is too big to complete in a single sprint. The estimation provides the Product Owner with input on the ordering of the Product Backlog. If the team has no idea how to create a Product Backlog item, there is a possibility to start another 10 minute time-box to explore this. Or the Development team identifies a spike to further investigate possible solutions. As you can see in the image, there are a few decisions to be made during a Product Backlog refinement meeting. This overview will help a Scrum Team in losing focus or forgetting options to get an item in a ready state. This flow has been created by combining successful practices applied by several clients and is a useful ‘cheat sheet’ for Scrum Masters and Product Owners to get the focus back into Product Backlog refinement. Good luck!
Mar 29, 2016 Read blog
Stephan van Rooden
What do you do during Product Backlog refinement? How do you prevent discussions going off track or in too much detail? Who should be there? When do you estimate? In this blog series, you will get some good practices and guidance for having better, more effective and more vivid Product Backlog refinement. This series will consist of three posts: Before you bring an item into a meeting What do you typically do during a meeting focusing on refinement? Facilitating a meeting on Product Backlog refinement The refinement meeting The scrum guide states: The Scrum Team decides how and when refinement is done. Refinement usually consumes no more than 10% of the capacity of the Development Team. In practice, this means that most Scrum Teams plan three time slots of each one hour, throughout the sprint where they spend time with the Product Owner and stakeholders. This should be enough time for a Product Owner and Development Team to create a flow of items in a ready state. Ideally, a Scrum Team has 2 sprints of ‘ready’ work on the product backlog so if a product owner goes on a holiday or falls ill, the team can go ahead. We find teams struggling to gets enough work in a ready state for the upcoming sprint. Vague items being brought into Product Backlog refinement and the Development Team getting caught up in discussing any possible solution are signs of refinement gone wrong. Such discussion are consuming the energy of everyone in the meeting, including those involved in the discussion. When facing this teams often set a 10 minute time box to discuss a Product Backlog item. If after 10 minutes there is still no direction of a solution, the discussion is stopped and the Scrum Team decides what to do next. For example, it might be that the Product Owner needs to verify with his stakeholders some assumptions or that the Development Team needs to do some homework on the possible solutions. Sometimes it might be useful to involve stakeholder in product backlog refinement. When stakeholders and the Development Team are in direct contact with each other, it prevents both sides from making estimates based on assumptions. Like Al Sapienza said in the Steven Seagal movie ‘Under Siege 2’: “Assumption is the mother of all f*ck ups.” Spikes Spikes finds their origin in Extreme Programming and are described as ‘A story or task aimed at answering a question or gathering information, rather than at producing shippable product’. So during Product Backlog refinement a Development Team can decide to create a spike. This spike will be added to the Sprint Backlog of the current Sprint. Preferably will bring back a result before the next meeting so the item can be brought a step closer to being ready. Two characteristics of a spike: Have clear objectives and outcomes for the spike. Just like any other sprint backlog item Be timeboxed. Start with the timebox of one hour and after that decide if you need more time. The biggest risk when introducing spikes to a Scrum Team is that they embrace this type of task as a tool to create detailed plans and designs. A spike is an exception, not the rule! Activities during Product Backlog Refinement Performing the activity of Product Backlog Refinement is of primary interest to the Product Owner. It is up to this role to have an effective Product Backlog refinement. For each item they decide to bring forward during refinement they need to have a clear idea of what they would like to achieve for this item. In the movie by Henrik Kniberg, ‘Agile Product Ownership in a Nutshell’, three things you typically do during Product Backlog Refinement are mentioned. Slicing, estimating and writing acceptance criteria for Product Backlog items in collaboration with stakeholders.. Slicing As stated earlier ,the purpose of Product Backlog refinement is to get Product Backlog items in a ready state. This means that an item should be small enough to be picked up in a Sprint. This may sometimes take some creativity to achieve. The story splitting cheat sheet is a great tool to help teams with exploring possibilities for splitting items. To practice slicing there is a great game to have teams see the value of splitting stories, Alistair Cockburn created the Elephant Carpaccio exercise. A word of warning, some teams have figured out how to slice items, they tend to slice up beyond the point it being necessary to make an item smaller. This is the time where a Scrum Master of Agile Coach should intervene and explain the team the purpose of slicing. Estimation One of the most debated activities when teams apply the Scrum Framework is the point of estimation. Scrum simply states that items should be estimated, however how to estimate is left blank. Whatever work best in your situation. First, let’s be clear, you can always estimate! Even if something is unclear, you can come up with an estimate (most likely something big). Assigning an estimation is not the same as getting an item in a ready state. Product backlog refinement would be a lot less difficult and time-consuming, if everyone involved agrees that an estimation is by default incorrect. It doesn’t matter which technique you apply. If you cannot get past that point, any technique will result in the same frustration. If you do get everyone to agree on this, then you might consider the following techniques. T-shirt sizing A great technique for quickly estimating an item. It’s fast and easy to use. Everyone has an idea of the concept of small, medium or large. Magic estimation, a technique for fast estimation of multiple items I would recommend reading this blog on how to do this activity. Planning poker Best known technique for facilitating team estimation. Planning Poker has its origin in the widepand delphy method and was made popular by Mike Cohn. A time-consuming technique but very effective. Acceptance Criteria Adding acceptance criteria to a new feature is not new, we have worked this way for decades. This activity is done together with the entire Scrum team, preferably during Product Backlog refinement. The level of detail when writing acceptance criteria depends on; The item at hand The level of knowledge and experience of the people involved and most of all How good the Product Owner and the Development Team interact. Product Backlog refinement meetings can be very efficient when the Product Owner more or less knows the level of detail the Development Team needs. Just using the user story template can be enough for the Development Team to have an item in a ready state. A Product Owner should spend less time on writing acceptance criteria and more time on frequent inspection and adaption when the item is in development. From my experience this should be enough to get started with product Backlog refinement. In the third, and last, blog, I will share some insights in how to facilitate a Product Backlog refinement meeting.
Mar 21, 2016 Read blog
Stephan van Rooden
One of the most challenging activities in Scrum is Product Backlog Refinement. During training courses I get many questions on this activity. What do you do during Product Backlog refinement? How do you prevent discussions going off track or in too much detail? Who should be there? When do you estimate? In this blog series, you will get some good practices and guidelines for having better, more effective and more vivid Product Backlog refinement. This series will consist of three posts: Before you bring an item into a meeting What do you typically do during a meeting focusing on refinement? Facilitating a meeting on Product Backlog refinement ‘Ready state’ The goal of Product Backlog refinement is to work with the Scrum Team and stakeholders (when relevant), to get Product Backlog items in a ‘ready state’. What does this mean? This basically means that the development team has the idea that an item is: Clear enough, so they understand what stakeholders are asking for and why they are asking for it. Small enough, so the items should be small enough to get done within a sprint (typically a few days of work) to comply with the definition of done. This activity is all about interaction between the Product Owner, Development Team and stakeholders. If you were expecting a blueprint for a ‘ready’ item you clearly need to do some homework on agility. When an item is ready depends on many different aspects like experience of the Scrum Team or knowledge about the product. It even differs per item when a Development Team considers it to be ready. This activity takes time and doing this right saves a lot of time in Sprint Planning. Before you bring it to a meeting The most important part of Product Backlog refinement actually is before you start refining. The most ineffective use of a Scrum Team's time would be to refine an item that doesn’t contribute to the product vision. For a Product Owner, one of the first steps when a stakeholder has an idea is to find out what this person would like to have and why they need it. A common pitfall is that a stakeholder asks for a solution, the 'how', and a Product Owner in all it’s enthusiasm fails to retrieve what they would like to have and why they need it. Numerous times I have seen stakeholders ask for an iPad app. This sounds incredibly valuable and any developer would like to spend time on this over working on some legacy application. However, when the reasons behind the solution are unclear it will most likely end up somewhere hidden in the app store. So, knowing the reasons behind the idea makes it easy for a Product Owner to judge whether this idea contributes to achieving the long-term vision of the product. If not, a Product Owner might consider to work on it anyway since it opens up a new market opportunity but most often it would be better to focus on those items that contribute to the team’s reason for existing. If these boxes are all checked then comes the most important decision. With the knowledge the Product Owner has, is it a valuable idea to create? Does this item have a fighting chance to be picked up by the team or will it end up somewhere at the bottom of the Product Backlog. I have seen Product Owners collecting every question ever being asked over a course of 8 years ending up with 12,000 items on the Product Backlog. A complete waste of time and effort. Even a product backlog with 100 items might be too much for a single team. As a Product Owner, you should ask yourself, how big is the chance of this item being picked up if it initially will be placed on the 40th position on the Product Backlog? Wouldn’t a stakeholder be happier in the long run, if you spare him the false hope of his idea ever to be picked up? As you can see in the image above, there will be a lot of conversation between a Product Owner and stakeholder before it ends up on a product backlog. If the Product Owner does not consider the idea to be valuable, the stakeholder has two options, provide a better business case for the idea or just accept it just wasn’t a good idea to begin with. Our best advice for good Product Backlog refinement is to prevent everything to be discussed in Product Backlog refinement. Stages of Readiness One of the key pillars of the Scrum framework is ‘transparency’. For managing the Product Backlog, this means that it should be visible for the Scrum Team and stakeholders what the order is and in what stage of readiness a particular item is. The image below shows an example of a Product Backlog Kanban board. Typically a Product Backlog item goes through three refinement meetings before it is considered to be in a ready state. First, when a stakeholder comes with an idea or wish, the team would roughly estimate the size of the item. A very fast way to do this is by 't-shirt sizing'. Nobody knows the exact size of a small sized t-shirt but everybody has an idea about the relative difference in size between a small and medium sized shirt. It is the first input for a Product Owner to get an idea on the effort involved in realizing the item. The second part is to assign story points to the item but again in a quick and dirty way. The format often used is Magic estimation or Silent estimation. This is estimating effort without having long and in depth discussions on the item. The final stage before an item is considered to be ready by a Development Team is to do planning poker. This is a frequently used technique for estimating items. This technique is time consuming so preferably you would only apply this for items you actually want to be realized and based on previous estimation you have considered to be valuable enough to spend the effort. Hopefully, this post has provided you with some ways of improving the efficiency and effectiveness of Product Backlog refinement. In the next blog, which will be posted next week, I will explain what typically happens when you set up a meeting to refine a Product Backlog item.
Mar 14, 2016 Read blog