Note: This is a story and recollection of one of my past experiences. While it is based on my true experience it may contain some fictions at places.

Around mid-December, I was invited to a briefing meeting one day on a new project that I have been hearing for a while. As a person who has been in the company for a while, and ran large transformation project in the past, I know the drill and what to expect. As I expected, it was the usual high-level explanation and sharing of a new project that they are going to run, and as I expected as well, our team who is currently responsible for a related product is asked to take part in this new initiative.

Our team is the first team to pilot and successfully operate under Agile banner inside our multi-national organization here in Japan. Recently, we have been asked to take over stewardship of a product that was produced and expanded in previous projects. Looking at the rough track record of the development in the past, the stakeholders for this product are critical on introducing changes to the current product. When they heard that our team works on Scrum/Agile than the typical Waterfall approach they are used to, they are even more concerned. And this is what the meeting is about. At the end of the meeting, I received a laundry list of typical questions such as: ‘what is sprint planning? who should attend? who will write the user story? who should come to the sprint review? …’

This is not the first time I was asked these kind of questions. Answering these questions need a holistic view of how Scrum is and it will require a Scrum introduction/crash-course at a different time. Only this time, I wanted to try something different.

Scrum is logical. Not a lot of people realize that. Many thinks of it as a recipe, a procedure, a method, to be followed, just like Waterfall method. Scrum is also simple. Once you get into the basic ideas it is easy to understand the necessities that the framework addressed. It’s like learning how to ride a bicycle. Once it all clicked, you will never forget! The problem is how to get to this level understanding. In my experience the best way to learn is ‘Active Learning’. And that is exactly how I wanted to address these questions.

The new years went by quietly. As usual, people started slowly after the new years, which is a blessing. I was able to spend some time to explore various ways of the approach for this session. I wanted it to be around something that is close to people experiences, so that they can easily engage in discussions, and but sufficiently representative of Scrum framework, as not to lose the main ideas behind it. And, I found an idea.

“You may all come here and expect me to introduce and rehearse about the Scrum Framework with all the loop charts and diagrams …”, I said opening the discussion meeting that I titled ‘Scrum Introduction’. “Well, rather than getting you bored with what I believe you already seen many-many times, I wanted to do something different.. I want to do a little of role-playing. So, please follow along.”

“You are 6-months to your wedding that you meticulously prepared. You had the venue booked, the catering prepared, the proceedings thought of, the invitations sent out, and you have chosen the most beautiful wedding gown you ever laid your eyes on. Just one problem, it is a little tight around the waist (uh.. oh). So wanting to be sure you looked absolutely best at the day, you set this goal in mind: ‘I will lose 5kg of weight for the wedding.'” I paused, to let the idea of losing weight take a good foothold in their mind. “Now, please tell me, what will you do?” This was the premise of our discussion. I drew a large circle and wrote: ‘-5kg in 6m’ at the center.

“I will stop eating rice!”, one of the lady commented immediately grinning toward me. I know she was half-serious on the comment, but as a person who been working among the Japanese society getting the first response is usually is the most difficult. I know I will be forever grateful to her for taking this first step. “Very good!”, I wrote that point on the whiteboard. ‘So, I will now not eat rice again.. ever..’, I said half-joking and smiling. “I’m going to die.. “, another person commented. Everyone laughed.

“Well, we have 6-months, so if we lose 1-kg every month.. “, said a lady from strategy / planning function. I can see where she comes from, and it sounds very logical breakdown of goals. “Excellent! Now we have a target for every month. ‘Drop 1-kg every month'”. I noted that on the whiteboard as well. “So, what should I do if after 1-month I didn’t drop 1-kg?”, a probing question on options. “Add sport!”, a gentleman who has been sitting quietly suddenly gave an idea. “What a wonderful suggestion!”, I jotted down the idea.

“I also suggest, that you start measuring how much your weight currently is”, he quickly added. “Very important indeed!”, I added that.

“How about doing a reporting meetup with your friends every week?”, a suggestion from another lady. I am always amazed how Japanese people sometimes have this nifty methods of getting people in their group motivated. And yes, this is one of the common thing they have. I added that to the list

“So, lets see.. If I extended this idea of breaking down the Goal to weeks, I can say that I want to aim of losing 250g every week”, I extended the big-circle goal to create a tree of months and weeks. In each week I wrote ‘-250g’. “I want to focus on the first week. Lets say that we are going to start this from the following Monday, and the method is the ‘not eating rice’ method you suggested, how is my week would look like? Remember, we have the reporting meetup on Sunday!”

I drew a table of with days of the week in the column, and ‘breakfast, lunch, dinner’ as the rows. So, the group decided that we should avoid rice and be a ‘goat’ eating salads for dinner. Breakfast and Lunch can be standard, but maybe less rice a couple of days in the week. The last day should be the ‘reward’ day. So, Yakiniku-lunch is in order. We should also weight ourselves in the morning everyday, and keep record of what we ate and our weight for the day.

“Now lets, fast forward a week after. You have executed your week plan, you stick to the plan, eat less rice, and you have a record of what you ate and weight everyday. Now, it is time for the super important ‘reporting meetup’ where you are telling your diet story to your friends and the result. Imagine if you’re telling them a success story of how you shaved off 250g in one-week! What would be their reaction? I am sure that they will be praising and be happy for you. What should you do for the following week? Do the same.. right?”. Some people nodded their heads. I know I rushed and could have engage them in the discussion, but I’m a bit pressed on time, so I wanted to get them into the important question. “but.., as what typically happens, what if we didn’t meet our goal? I am sure our friends will start giving us suggestions. What would that suggestions will be?”

“Skip breakfast!”, someone shouted. “Very stoic”, I smiled and wrote it on the whiteboard.

“Now we should do some sport?”, the same gentleman suggested. “I cycle almost everyday myself”, I nodded in approval.

“.. So now, we can modify the plan to incorporate Sport and eating ‘less’ breakfast. I crossed breakfast on some days, and added some markers indicating sport day to the table.

It is time for me to try to link this back to how Scrum works. “Our team works pretty much the same way as this”. I avoided the word Scrum and instead use ‘our team’ as not to let them lose focus. “We work with a series of goals that if achieved brings us closer to the ultimate goal. Which in this diet story is to lose 5-kg in 6-months.”

“So now we know that a Goal need to be descriptive, and a way to measure if we achieved that goal or not. In the first week, our goal is to lose 250-grams, and the way to measure it is to weight ourselves. We then plan our week to achieve that goal. This is our week diet plan, where we plan what we eat everyday, and weight ourselves every morning. At the end of the week, we will measure where we are at and based on that feedback we will change the plan and the goal for the following week. Maybe we will set for a more stricter goal of losing 300-grams of weight.”

“Let me give you a bit of explanation of some of the mechanic in Scrum to give you a bit of construct before we continue. A sprint is a timebox. Our team use a 2-weeks timebox as a default. Inside this time-box we are chasing a number of Goals. Each goals has a plan and a way to measure the completion of a goal. At the start of the Sprint we have a Sprint Planning, and at the end of the Sprint there is a Sprint Review.”

“So, based on your understanding now, what is a User Story and Acceptance Criteria?”

“Goal and how you measure?..”

“Excellent! To me a User Story is a goal that is written from User perspective, and the AC is how we measure if we met the goal or not”

“Now, what do you think is a Sprint Planning?”

“It’s a planning session.”.

“Correct. But what do you plan for?”

“Plan for the goal?”

“Excellent! Which goal? All the goals?”

…

“Aha! Now if its our own diet plan, the answer is easy as they goal is pretty easy and we can decide by ourselves. Not so quite for product development. If we are drawn to projects, the time is usually fixed, deliver x by y. But, products are not that simple. Bring in profit/revenue is the usual ultimate goal. This is complex and have so many factors involved such as timing, effort, cost, market conditions, customer voices, organization readiness, politics, etc. The person that have the visibility of all these factors and willing to fight and bring the most value to the customer of the product should be the one who decides and prioritizes the goals. We call this person as the Product Owner. It is a very difficult and demanding role as he is owning the product, and his success and failure depends (ideally) solely on the performance of the product.”

“So, now we understand that, what is the input to Sprint Planning?”

“.. Goals..?”

“Exactly! The prioritized list of goals is what we call the Product Backlog. The team will start discussing the goal and plan for the goal from the prioritized items. Does that makes sense?”. Everyone nodded.

“So, what is the output of the Sprint Planning?”

“Goals and plans?”, I nodded. “Very good. Please understand the implication of this very closely. If the Sprint Planning did not result on a plan, what will happen?..”, I paused waiting for an answer. However, everyone is anxious, looking at me to give them the answer. I continued l, “.. nothing move. The team will not be able to do anything for the sprint. That is the ultimate failure of a Sprint Planning.”

“So, the prioritization does not happen in Sprint Planning? Is it pre-prioritized?”, a question pops-out from the crowd.

“Good question. Yes, the input of Sprint Planning is a ‘prioritized backlog’. This should happen before the Sprint Planning happen. And, to further explain.. and avoid what misunderstanding, the prioritization can change at any time at the discretion of Product Owner. Remember that feedback can change the plan and goal? PO get feed backs all the time.”

“Shouldn’t the team give feed backs to PO as well?”

“Yes, of course! They are very critical feed backs especially on size and effort of a goal. However, the development team is usually very focus and busy with their work. We don’t want them to switch context at any time. So, we usually created a slot where the whole Scrum Team will gather and discuss on several product backlog and get feed backs. This is called the Backlog Grooming session”

“Now to get back to our Sprint Planning discussion, who do you think should attend the Sprint Planning?”

“The Scrum Team?”

“Of course, they are the one who creates the plan. But, who else should come?”

“Analysts.. ?”

“.. Project Managers? Architects?.. Everyone?”, I smiled. “Remember Sprint Planning is very important, and the Scrum Team must produce a reasonable plan. So the most generic answer I will say is ‘everyone that can contribute on creating the plan for the sprint’ should be invited. But that can mean the whole universe, right?”, I laughed.

“In execution, there are a lot of hints on who should be invited and it may differ for each Sprint Planning session. You will notice that some people that have strong domain knowledge that often contributes are usually get called on the meeting. When we expect to do large system designs or architectural changes, maybe people from architecture will get called. So, thematic changes are hints on who should we invite. Another hint also comes from the team themselves, maybe comments they made in the Backlog Grooming session. “

“Capturing all of this, preparing for the Sprint Planning is one of the work that a Scrum Master and Product Owner is working. Most often, the analysts in the Scrum Team helps us to prepare the materials and investigation for then upcoming sprint. This often ensure that we have enough knowledge in the team for them to make reasonable feasible plan in the Planning meeting.”

“Now, if we have a number of goals, and completed the first one in the 4th day. Where does the measure should take place? At the end of the Sprint, more than a week after?”

People shakes their head

“That’s right. Ideally we want to measure it immediately! If something is not correct, we want to fix it quickly as well, so we can be 100% focus on the next goal. The team can try verifying it themselves, but wouldn’t it be best if the people that uses it or knows how it should be, verifies it? In the same sense, it will be great if we can get answers on questions when we are developing things so we can change our plan quickly. And this is exactly what we are asking from people outside of the team. We want you as the business users, to help us clarify and verify quickly as soon as possible.”

“So, what is Sprint Review then? A lot of people thinks it is a review of the product where we verify each acceptance criteria or test cases one by one.”

“That is incorrect. It is far too late to give feedback on the details of the product every to weeks. Further, it is impossible to fit this in an hour or two meetings. I can sum the purpose of Sprint Review to three main activities: Update on the Status to our stakeholders, Update them on our current direction and plan, and get their Feedback on the direction. The focus is Stakeholders. This is a very special and important event for Product Owners to promote and ‘sell’ the product to them. I always tell people to imagine how every year Apple hold this product conferences, and how Steve Jobs present the product on stage.”

“We gave a demo to the stakeholders to give them an image on the state of the product. You maybe surprised on some of the feed backs they gave us. While you maybe in the adrenaline rush of developing and pushing more Features to the product, a stakeholder may say maybe we need to stop on adding more features as it blurs the purpose of the product. Some may sees that we have so many valuable features that we should focus on pushing the current features immediately to Production as this is what exactly what the market wants. And, some may have concerns on information protection and securities, and suggest as to work on those. These are very valuable feed backs to Product Owner and the Team. They will evolve the Product Backlog based on these feed backs as well. The second benefit is that it provides Transparency. When the resulting product is presented in front of everyone, there is no place to hide anything under paper and reports. What you see is what you get.”

“Now, I want you to turn your attention on the ‘Sprint’, the time-box. Why do you think we have a time-box? What is the benefit?”

“.. so we can check?”

“Good try! But probably not quite. Just like you are doing day to day work maybe in operations, and maybe in your life. We like things to be stable, repeating, expected, a routine. Maybe you have your routine of taking out the garbage. Or in our example, we have a routine of measuring our weight every morning.”, I explained. “The good thing of a routine is that we can predict what should happen at what time. This means, we can plan. We know that the Sprint is always two-weeks and the first day in the morning is our Sprint Planning. The team knows they need to clear that time slot for the meeting. The team also has a daily stand-up routine at 10am. So they plan and make sure they will get into the office by 10am. So, routine.. predictable.. able to plan, first benefit.”

“The second benefit, it helps limit the size of goal and planning. Remember the 6-months 5-kg weight loss program? Think about how difficult it is for us to meticulously plan our lunch everyday for the next six months. We all are well aware how diet plan changes every week, right?”, able to relate, everyone laughed. “It ensures that a goal must be achievable in one sprint. PO and the team will be collaborating to break down goals to break down big goals to smaller ones.”

“Third benefit, as the cadence is regular, the productivity of the team should pretty much stable for every sprint. This helps the team to reflect on how they can improve and be more productive sprint after sprint. In act, this is so important hat we have specific event to do this, Sprint Retrospective. The regular cadence and productivity also helps PO for forecasting which in the end gives more transparency to the stakeholders”

“So now, we have come full circle. Were you able to grasp behind the idea, and do you have questions around all of these?”

“If there is any requirement changes, do we need to create a ‘Change Request’?”, a business member asked.

“Ideally, no. Due to the nature of our iterative approaches, you always have the opportunity to change things in the next iteration. However, the priority of this change will depends on PO determination, and that may mean that some lower priority items not get delivered at a certain time. Speaking of which, you touch a very good point. Especially when integrating with a traditional project where delivery at specific time is required, there is a need to understand what is being delivered and when. We used a forecast in the past to do this, and certainly such a report can be useful in Sprint Review as well. “

“Should we attend the Daily Stand-up?”, ask another business member.

“Depends on where you are. If you are part of the team that is executing the plan personally toward the goal then Yes! This is a team collaboration effort. You need to communicate and sync with your team mates if your plan is still valid, and if you need help or not. If you’re not executing personally, then maybe you don’t need to. No one is stopping you to observe though. For example, the PO frequently observes our daily stand-ups but very rarely participate in our discussion. He does give us input if required.”

And that is pretty much the end of our discussion, and about time we end this discussion “So, I hope this all makes sense to you and answers most, if not all, your questions. If you have more questions, please email me and I’d reply or maybe setup another session.” I can see everyone have a good look and understanding on this. “.. and if you need pointers on these Scrum stuffs, just remember and think of our ‘diet plan’. I am sure that will help you a lot. Thank you.”