Lean Coffee, is this like skim milk and coffee with no sugar?
It could be; however, for those of us who attend this Saturday morning meetings, it is a structured, agenda-less meeting session. If you remember we did not have an agenda last Saturday, and next week we will decide it again before we begin to talk? This is what is meant by an agenda-less meeting. We decide at the start of the session. Besides asking for topics from the participants, the facilitator will ask for the participants to dot vote to rank the topics based on the interest of the participants. The facilitator uses a Kanban board with limit of one topic at a time and a time box to better manage the session topics. All these are used to focus on the participants needs.
Voting, there are a few ways to consensus?
Just like there are several ways to vote during an election, there are a few ways to consensus vote.
Let’s begin with the simple vote, yes/no, from Roman times. Thumb up or thumb down as the Romans did, hand up or down, or glasses up for yes at the bar or restaurant. Though this may work to answer the question who wants cake, when you only have cake to offer, it does not always work. Why are people not voting?
You cannot get everyone to agree to yes/no? Use the thumb up, thumb down, and thumb sideways. When someone cannot agree or disagree, it is time to ask why? Think of it as yes/no improved. Allow for neutral vote and communicate a concern before deciding yes/no. Does everyone want cake? Thumb sideways. Does it contain nuts? I have an allergy.
When our discussion from Saturday, with the fist of five voting option. We are going to vote using your five fingers to represent your degree of support.
- 1 finger means I am 100% in support
- 2 fingers mean I am in support with minor concerns we do not need to discussion
- 3 fingers mean I have concerns we need to discuss
- 4 fingers mean I have an objection we need to discuss
- 5 fingers mean I am not in agreement and we need to stop
The fingers are a visualize tool to communication the level of resistance and objection.
Sometime you just need to understand the level of support for a topic. This is where dot voting can excel. Need to determine an order or ranking? I have ten things. I give everyone two votes to determine their top two items. I am using the 80/20 rule. It does not always need to be the 80/20 rules, determine how many votes required to get the result you need.
Before we end, sometime the Product Owner needs to rank features or stories. In this scenario they may choose to use either 1-10 business value ranking or Weighted Shortest Job First (WSJF). WSJF is a prioritization model used to sequence work, such as epics, features, or capabilities to produce the maximum economic benefit. © Scaled Agile, Inc.
Planning Poker, are you ready to play cards?
I have a list of items I want to size. I do not want to use actual metrics because I have difficultly determining the time required to travel from A to B in hours and minutes accurately with the use of a GPS. Therefore, I decide to size items using a relative estimate. By that I mean, I am going to compare items to determine what is smaller and larger than the next item. In this example, I am using the weight and size of the items. First item is sized as a 1. As I compare the second item, I see it is three time the weight and size of the first item. Since I sized the first a 1, I say the second item is a 3 size. However, as look at the third item, I realize it is about one and one-half smaller than the second items and one and one-half times larger than the first. The third is a 2 using the scale of 1, 2, 3, 5, 8, etc. Wondering what I was looking at? A gold ball, softball, and baseball. It could have been a strawberry, a ripe and juicy orange, and a lime. 1, 3, and 2 relative speaking. For the fourth item, I will compare it to the third, but some team members may choose to compare the fourth item to the first three. This is okay. Additionally, you could do this with an item.
Do I need to use numerical values? No, I can size them quickly by using tee shirt sizes of Small, Medium, Large to keep it simple. However, for user stories, it is more common to really use the 0, 1, 2, 3, 5, 8, 13, 20, 40 and 100 or the Fibonacci sequence numerical values via a technique called Planning Poker. I do not want to use hours or days for anything other than a small work tasks since it is inaccurate and wasteful. What is Planning Poker?
Planning Poker is team consensus estimating technique used to size PBI (Product Backlog Items) using story points. Normally the numerical values mentioned in the prior paragraph or Fibonacci sequence though teams have been creative with the numerical values used. How is it a team consensus estimating technique?
- All the team member participating in the creation of the solution are asked to size the PBI
- Ensuring objective estimates are encouraged via a synchronous estimate reveal
- When there is no team consensus, the team discusses the thinking behind their suggestion
- More than round is used to eliminate estimate variation
- Team organizes around the number of rounds required to determine the PBI size
How might this look like? Decide on a PBI item which the team feels is ready to be sized. The team decides the smallest item in the list and assigns it the smallest value. Sometimes a discussion occurs that the smallest story point is too small. The same item was sized previously using the next story point value. It does not really matter if it is a 1 or 2. Team decide. Now lets begin with the second PBI. Each team member determines a size values, also known as story point, from their deck of cards based on the relative size of the first to the second PBI. Follow the same think described in the opening paragraph. Next the facilitator asks each team member to reveal their story point/size suggestion now. If team consensus is achieved, facilitator records the PBI story point and moves on to the next PBI. If there is no team consensus, the team members at either end of the story point range shares their thinking for their selection. Team discusses. Another will share their thoughts. The facilitator asks if they are ready to redo the sizing? The facilitator asks each team member to reveal their story point now. They will discuss and re-size based on the team agreement for how to arrive at team consensus size for the PBI.
What happens if the team is remote? Use video conference with cameras on to bring the team together. Get each person a set of story point cards. When the team is ready to show their story point suggestion, place the card in front of the camera at the same time so the Scrum Master can assess the story point range. Other than these, follow the same plan as if the team would be c-located. In either case, poker hats optional, but poker faces are encouraged.
Sprint Planning, the what and how?
The Scrum Guide describes the Sprint Planning event/ceremony as a collaboration and discussion of the Scrum Team on the desired high-priority work for the Sprint and defines the Sprint Goal. The ScrumMaster facilitates the meeting. The Product Owner describes the objective of the Sprint via a set of ranked PBI (Product Backlog Items, the pinks) and also answers questions from the Development Team about execution and criteria of satisfaction for each PBI. The development team, people on the team who deliver the product increment/solution at sprint end, begins with data on its velocity and availability during the sprint to determine the PBI for the Sprint Backlog. Thereafter, they continue their collaboration to determine how much of the high-priority work it can accomplish during the Sprint and update any information radiators (this could be a sprint backlog, sprint goal, risk, dependency, and team mode visuals/tools). It is customary to bring the Scrum Team back at the end to share this information with the Scrum Master and Product Owner.
What is the beginning and ending artifacts? I am going to use our knowledge of the past product increments, ranked PBI list, past velocity data and team availability / capacity to determine sprint backlog and sprint goal. I might want to also include risk, dependency, and team mode visuals/tools to be more transparent.
The Scrum Guide guideline is that Sprint planning is limited to a maximum of one day / eight hours. Scrum Team plan two hours for every week so expect to need one-half day for a two-week sprint. Four to six for a three-week sprint. As was asked, why does it take longer? The work of the Backlog Refinement leaks into Sprint Planning extending the time required. Why is so bad? If open questions, which could have been answered between the Backlog Refinement end and start of the Sprint Planning are unanswered, PBI(s) may be dropped or labelled commitment which can be avoided by better planning.
Team plan to understand and collaborate the sprint journey they travel together. The do not plan to have a perfect, rigid plan. Remember the Agile value, welcome change over following plan.
Daily Scrum, did you say only15 minutes?
Yes, the Daily Scrum is a 15-minute time box for the solution creators, the development team, to inspect their progress toward the Sprint Goal. Traditionally they begin with sharing how their own work is going and asking for help to slay impediment as they consider if they are on track to meet the Sprint Goal based on a 48-hour time slice, past 24 and next 24 hours. Think of as an inspection and adaption the product and process on a daily basis. Why does inspection and adaption ring a bell?
If the development team is the only mandatory participant, who else might attend? The ScrumMaster typically attends to coach the team on Daily Scrum later and help with impediments when asked. The product owner likes to listen in. Others might listen in too.
If I was to poll 50 coaches, I might get different opinions on the PO / SCM responsibility during this ceremonies. Here is what I commonly hear which may be different than the 2020 version of the Scrum Guide. If you are performing work to deliver the sprint goal and you are the PO or SCM, encourage their participation.
Have you noticed that the team may stay so more time to talk afterwards? This is not uncommon as they gather to address some questions or concerns which did not need to take up the time of everyone in the Daily Scrum. Plan for this.
Sprint Review, adults doing show and tell!
It is safe to assume that after spending a few days working on a user story the need to show off your work would come up. There is nothing wrong with share your work accomplishment with others. The Sprint reviews focus on the product increment, the potentially shippable increment, created during the sprint timebox. The Scrum Team shares what they finished and did not finish with the stakeholders for them to inspect and get feedback. When the feedback warrants a change to the future plans, they adapt the Product Backlog based on this feedback. The Product Owner uses the feedback to decide if all or part of the release is potentially shippable. Why a Sprint Review? Inspect and adapt opportunity for everyone involved. Who is involved in the discussion?
The Scrum Team take the role of the host. The stakeholders are the invited guest. Who? Anyone that is impacted or has interest in the product. This could be any level managers, impacted functional departments, supporting “operational” team members, product sponsors are commonly invited to attend and give feedback. It is best to have a full room of people to provide feedback from a diverse set of people to arrive at a product they can all support. Please do not rush this gather just because there is a large audience present. It is not uncommon for this event to take two hours. The Scrum Guide suggestion is one hours per time box week.
How do we close the completion of the Sprint? Celebrate. Acknowledge. Thank those who came and those that worked to make it happen. Celebrate!!!
Sprint Retrospective, it ain’t over until the retro is done!
When a Scrum Team spends time delivering the product increment, things happen. It is always a good idea to reflect, inspect, and adapt. What better time to chart a better course for the next time box. During the retrospective the Scrum Team discusses what went right, what did not go well, and areas for improvement in the Sprint. They inspect their process, tools and relationships with the intent to make tangible plans for how to improve. No reason to repeat what did not work or take a chance on something new to improve. It is not uncommon for this event to take two hours. The Scrum Guide suggestion is one hours per time box week. If we want to have the best retro, it is recommended that the PO attend. It is best to have feedback from a diverse set of people.
How do we close the retro? Celebrate. Acknowledge. Do a team building game. Thank those who came and those that worked to make it happen. It ain’t over until we sing and do the happy dance! Celebrate again!!!
Note: when you take the exam, the guide says to schedule 45 minutes per time box week.
Backlog Refinement, it ain’t in the guide?
No, you will not find Product Backlog Creation session(s). You will not find Release Planning meetings. You will not find Backlog Refinement meeting either.
If this threw you for a loop, did you know there are only three Scrum Artifacts. Three.
Scrum uses three artifacts to help manage work. All three are defined and described below.
Product Backlog, if it is not in there, it like it was never said.
The Product Backlog is a collection of all the stakeholders, the Scrum Team is a stakeholder, wants and needs. The list is a varying level of completeness. However, it is best that the list is an ordered list of everything that is known to be needed in a product. This way the team can focus on the important work first. Do not worry, it is constantly changing, evolving so it is never complete.
As mentioned previously, it is somewhat magical since there is no word how it got here. What document was used to determine when the Product Backlog item can be introduced to Sprint Planning. Definition of Ready is the document created by the Scrum Team and also not listed in the Scrum Guide.
Sprint Backlog, an output of Sprint Planning.
“The Sprint Backlog is a list of everything that the team commits to achieve in a given Sprint. Once created, no one can add to the Sprint Backlog except the Development Team. If the Development Team needs to drop an item from the Sprint Backlog, they must negotiate it with the Product Owner. During this negotiation, the ScrumMaster should work with the Development Team and Product Owner to try to find ways to create some smaller increment of an item rather than drop it altogether.” The guide did a great job of defining this why not use it.
Potentially Releasable Product Increment
“At the end of every Sprint, the team must complete a product increment that is potentially releasable, meaning that meets their agreed-upon definition of done. (An example might be fully tested and fully approved.)”. The guide did a great job of defining this too why not use it.
Depending on your environment, Potentially Releasable Product Increment can simply mean that is ready for another test environment. This does not change the intent. Potentially Releasable Product Increment is ready for production even if it not the next step.
Another artifact might be a Sprint Burndown chart, dependency chart, risk chart, or team mood or happiness chart. From this list the Sprint Burndown chart may be something new to you. Team mood or happiness chart is what you think. How happy is the team today? However, the Sprint Burndown chart does not explain itself as well. “A sprint burndown (or burnup) chart is not an official Scrum artifact but many teams use it to communicate and track progress toward the sprint goal during the sprint. Sprint burndown charts helps teams gauge whether they will complete the work of a sprint. Burndown charts also reinforce the Scrum values of commitment, focus and openness and one of the three pillars of empirical process control: transparency. “
Please take a moment a read the Scrum Guide.