Krystian Kaczor

Interesting times have come. Due to danger of coronavirus spread many organizations decided to switch to the remote work model. Besides the influence on Scrum implementation, this might be a new situation for you personally.

A User Story is the most widely used Agile Practice for capturing needs and requirements and describing Product Backlog Items. To get the most of any technique it is good to understand the why behind it not just the what. Let’s discuss how to write better User Stories in Scrum.

Let’s start with a question. When is the Sprint Planning over? Usually, the first answer that comes to mind is “when the time-box expires”. It is a good answer. However, Sprint Planning is a maximal time-box. We can end the Sprint Planning earlier, can’t we? Yes, when we are done with planning, we can go to work. How do you know you are done with planning? When we have identified all of the tasks. When everybody is fully booked. When we have no hours left. That’s where you got it all wrong. It is not the purpose of Sprint Planning to make sure everybody is busy. Even if, some electronic tools support it that way. The what and how of the Sprint Planning We need to answer two questions what is the objective of the Sprint and how are we going meet it. The Product Owner comes with a proposal of the Sprint Goal and Product Backlog Items supporting it. The Development Team looks at the latest product Increment, projected capacity and past performance. Based on the data, the Development Team forecast what can be achieved. The whole Scrum Team collaborates on crafting the Sprint Goal, so everybody understands why are we building the Increment. Then the Development Team builds the Sprint Backlog. They do it by designing the system and decomposing the work for Product backlog Items taken into the Sprint. There are many ways of decomposition and none is preferred by Scrum. The most common practice I see is splitting the Product Backlog Items into tasks. What is the proper size of a task? Good idea is to have tasks of the size of one day of work or less. This means that tasks are quite small. Why? It makes the Daily Scrum effective and progress of the work clear. When we have small tasks, everybody is able to get something done between Daily Scrums. But splitting all the work to small tasks can take a lot of time. Do we need to split all Product Backlog Items into small tasks? For some Product Backlog Items, it won’t make sense to split. For example, fixing a fairly simple bug. Then don’t split. For the rest, make sure that you have a fairly good plan for the first days of the Sprint. The rest of tasks will emerge during the work. The challenges of planning the work It is not possible to predict all the work in complex environment building innovative products. Decomposing the work is nothing else, but predicting the future based on assumptions. Some tasks are going to take longer, some are going to take shorter and there will be new ones. You start working on something and you can discover many new things you didn’t know. Therefore, the Sprint backlog is going to be updated constantly until the end of the Sprint. The purpose of the Daily Scrum is to look at the current state of the Sprint Backlog and decide what to do next to achieve the Sprint Goal. There is also a misconception in terms of using the capacity of the Development Team for planning. Some believe that calculating the team capacity in hours and estimating all the task is the best way for to plan a Sprint. I think we all can agree that it will take a lot of time. Let’s look at using the capacity without detail calculation. Basically, check with your team if there are any holidays in the current Sprint or absences. Now, look how does it compare to full capacity and what is the impact to the Velocity. It is simple as that. Please, if you still want to go with precise calculations, remember to leave a buffer for the unexpected. The Development Team needs to feel confident with the forecast built. Pushing them for stretch goals will get you a squirrel burger at best. What about the traditional resource and capacity allocation? How are we going to make sure that everyone is busy? Scrum is not about making everyone busy, it’s about building valuable products. Being busy is not the same as being productive nor creating value. As part of the Agile family, Scrum promotes the idea that the best solutions come from self-organizing teams. So let the Development Team self-organize around the Sprint Goal and update the Sprint Backlog accordingly during the Sprint. Having tasks assigned to individual team members ruins the opportunity to self-organize. Assigning tasks moves commitment and focus on delivering the Sprint Goal as a team to complete tasks assigned to me. Each member of the self-organizing Development Team shall pick next task when he or she finished the previous one. The selection of the new task shall be based on answering “What is the best thing I can do to help the Development Team meet the Sprint Goal?”. There is also no rule against multiple Developers working on the same work item. When the Development Team discovers, that the work in the Sprint differs from the forecast built, they can negotiate. The Development Team can work with the Product Owner on removing or adding Product Backlog Items to the Sprint Backlog. The scope of individual Product Backlog Items can be also negotiated. Changes cannot impact the Sprint Goal. That is another way the Sprint Backlog changes during the Sprint. Summary The outcomes of the Sprint Planning are the Sprint Goal and a plan of delivering the Increment. The work that needs to be done is represented in the Sprint Backlog. Sprint Backlog needs to be detailed enough so that the Development Team can forecast the work needed. Bear in mind that we want to create only a forecast for the Sprint, not a bulletproof plan. For the first days of the Sprint, the work is decomposed to small units and the rest will emerge. Self-organizing Development Team decides how to do the work as they go. Changes in the Sprint Backlog will occur as the work emerges or as the scope is negotiated with the Product Owner.

Clients and training attendees ask me "Can you use Scrum for something else than software?”. What they usually mean is building some other products or organizing team’s work. Let’s explore a more exotic idea. It’s beginning of a new year, the time when people make and try to achieve new year’s resolution. 92% of them will fail. About half will drop the goals within the first month of the year. People buying 3 months gym subscription will go there less than 10 times. How about using Scrum for your life? Scrum is about delivering value, reaching goals. Don’t you want to get more value and reach your goals in your life? Manage the Product Backlog Working on everything in the same time will lead you to fields of business and deserts of productivity. You need to stay focused to achieve goals and manage things to do so there can be only one list of things to do. Build your Product Backlog. What are your big goals for this year? They are your epics. Big chunks of work or big goals are demotivating and difficult to finish in Sprint. You need to split them into smaller items. Keep the epics SMART and smaller items INVEST. Product Backlog will grow and change over time, therefore you need to review it constantly. I would say at least once a week. Stakeholders will come to you with ideas and wishes important to them. There will be always new ideas and things to do, but the time is a limited resource. Be careful not to spend your resources on low-value items. Sometimes saying “No” and facing the consequences is the best thing you can do. What is the worst thing that can happen if you don’t do that item? Not much? Then say no. Plan Sprints Year to plan ahead is a too big period of time. Plan smaller periods of time. What should be your goal for the next release? What do you need to do in the Sprints for that Release? The length of Sprint and length of working day are fixed, they are time-boxes. So effectively you can manage only how much work you can take into a time-box. Plan your Sprints wisely. Don't take too much. Don’t overcommit. Usually, stretch goals are also a bad idea, but check how it’s working for you. You can always take more if you are done earlier. Keep some slack time for fun activities and hobbies. Are you working only in the Sprint or there is some maintenance going? What is your ideal day? Keep it visual and transparent Visualize your backlogs and keep them up to date. Doesn’t matter if you want to use paper To Do list or fancy electronic tool. Have the backlogs handy to look at them and updating them at will. Update your Sprint Backlog daily, and every day create a new plan for the next 24h. Some people like to do their Daily Scrum first thing in the morning, some prefer before going to bed. It’s up to you to decide when it the best time. Create a habit by doing Daily Scrum same time and place. Sometimes it feels like you have done no progress at all, but when you look at your list there is quite a lot done. Time-box work and monitor progress Something takes to long? The important task that you keep postponing? Slice it into smaller chunks, delegate or decide not to do it. Make a decision and keep moving. Wear a watch and look at it often. You will see the time passing and progress done it that time. A clock on the mobile phone is not enough because you don’t see it all the time. Use time-boxes for doing tasks. Estimate them, use Pomodoro technique or something else to create a habit of focused work. Take a break, then take another task. Do not strive for perfection. Done is better than perfect. Create list of criteria for items to know when you have done what you aimed for. If not all the items in your Sprint Backlog done at the end of Sprint, review why and decide what to do with them. Does the outcome of the Sprint affect others? Run a Sprint Review with stakeholders. Don’t mindlessly carry over to the next Sprints. Create blank Sprint Backlog and decide what to put there. Get a coach Being the Product Owner, the Developer and the Scrum Master doesn’t work well. You can not be in the process and see the process outside at the same time. You also won’t feel much of external pressure. Get a life coach to run good Scrum Retrospectives and talk about the whole process. Look at the goals from a different perspective. Discuss the consequences of your decisions. Get motivation and inspiration for going forward. From time to time you need to sharpen the saw to cut trees well. Conclusion As you can see, there Scrum framework is quite universal. That’s the reason why the scrum Guide cannot be very detailed. You can use Scrum for many things, even for your life. The rules in Scrum are based on common sense and time management. Whether it is building software product or other goal-driven creative endeavor, Scrum can be a game changer. It takes only 5 steps to implement Scrum in your life: manage the Product Backlog, plan Sprints, keep it visual and transparent, time-box work and monitor progress, get a coach. Don’t take my word. Try it and see if it works for you. Would you add more or change something? Share ideas in the comments below.

One of the arguments used against Scrum and a common misconception at the same time is the idea that quality is traded for speed in Scrum. As a PST with years of experience in Quality Assurance I decided to challenge this myth. I believe and I have seen many times that proper way of implementing Scrum leads to higher quality products delivered faster than using so called traditional methods. I will look into reasons for coming up with ideas of low quality in Scrum. Then I will explore the idea of quality. Finally I will explain how Scrum supports high quality products. Origins of the low quality myth Lets think for a moment where the myth is coming from. Looking into my experience as coach and trainer I can see two sources, one theoretical and the other practical. Looking for low quality in theory I can see how person learning about Scrum and Agile mindset can come up with wrong conclusions by relating her current context to proposed values, principles and rules. Besides of Scrum Master and Product Owner in a Scrum Team we have Development Team which consists of Developers. The wrong conclusion to make out of it would be "I don’t see a testing team nor testers in the Development Team so, there is no testing in Scrum”. The truth is that cross-functional Development Team should have also testing skills. Who is a tester anyhow? Tester is a professional within software development process responsible for conducting testing activities. We have also testing specialists equipped with testing skills. In Scrum we don’t want to have a role named tester in the Development Team, because it would lead to a person with that role being responsible for testing. The whole Development Team is responsible for quality of product and each team member has equal responsibility regardless his or her specialization. The Development Team composition should be optimize to deliver potentially releasable product Increment. Therefore the Developers need to have testing skills. Of course some of them will be better at testing, some will be less good. But nevertheless the testing skills will be in the team. The potentially releasable Increment needs to be in usable state and work well with the previously delivered increments. Therefore all the work should be tested in regards of business requirements and integration. The Increment needs to be Done, which means it needs to meet the definition of Done. This way we can ensure that it is transparent to everyone involved what is actually Done and what does it mean that a Product Backlog Item is Done. With the concept of definition Done comes another misconception. Who is deciding on the content of the definition of Done? The Development Team decides on the appropriate definition of Done for the product they build. One can come up with conclusion that in that case the Development Team will come up with the most easy and comfortable definition from their point of view. They will leave the tough part out. But, why would software professionals do that? Let’s leave that question for your own consideration. I have a better question for you. Where does the definition of Done come from or what is it based on? There should be some existing conventions, industry standards and company policies in place. And these are the cornerstones the Development Team should build the definition of Done on. More than that, the standards and work described in the definition of Done should reflect potentially releasable state of product Increment. We want to have ready to release Product every Sprint. This way the definition of Done will be stronger than the guideline used before and mandated each Sprint instead of at the end of the project. Looking for low quality in practice I am perfectly aware that you can meet teams which claim to do Scrum and have low quality products. I have seen teams which started new work with Scrum and quite quickly run into maintenance or bug-fixing issues. I have also seen teams which converted the current project to Scrum way of working and could not deliver a proper product Increment for many Sprints. So it is quite easy to draw conclusions that with doing Scrum quality suffers. Yes, I have seen it as well. But, still it is a pretty far leap to draw conclusion that it is fault of Scrum. Are you sure that the same team would perform better using a different way of working? Would they deliver more not doing Scrum? How do you know that what they are doing is Scrum? Maybe it is Scrum BUT created by removing Events, Roles or Artifacts? Doing Scrum is difficult in practice and it takes a lot of effort to go beyond mechanics by living Scrum values. Scrum doesn’t make promise to solve all the problems in teams or organizations. Scrum shows how effective their current practices are in building the desired results. It is their choice to improve the practices or modify Scrum to show less. The what and how of quality There is no need to open discussion and run into endless disputes when we have already coined definition handy. After IEEE 610 Quality is the degree to which a component, system or process meets specified requirements and/or user/customer needs and expectations. Assuring high quality is more than testing and fixing bugs when the requirements are implemented. We should optimize the whole process to create high quality with as little defects as possible. Quality by meeting requirements Many projects failed because someone did not tell about something important or was misunderstood. One of the areas where issues with communication are most visible are requirements. The best requirements written single-handedly is always a subject to open interpretation by the one implementing them. Direct communication and short feedback loops are the only effective way to make sure the Development Team will deliver the right thing. How are requirements specified in Scrum? One could shout "User Stories!” While writing User Stories is popular with Scrum, it is not required practice. Since the Product Backlog is the only source of work in Scrum, functional and not functional requirements should be placed there in any form comfortable to work with for all the stakeholders. Why the form is important? Because in Scrum we want to have all the stakeholders understand what is on the Product Backlog and collaborate on requirements. Product Backlog items are refined in collaborative effort by Product Owner and Development Team. This way is Scrum we make sure everyone is on the same page and we collect ideas from multiple points of view. During the Sprint the Development Team has a direct access to clarify and negotiate Product Backlog Items being worked on. Anyhow, there is still some room for misunderstanding. When are we going to be sure that what the Development Team built the right thing? On the Sprint Review we actually show the new product Increment and give opportunity to stakeholders and the Scrum Team to collaborate on what was done in this Sprint and what is the Development Team going to next. Quality by high quality work Everybody seen products which did not perform well in production environment or it is difficult to develop further. Doing the right thing is not enough. We need the product to do the right thing right. Maintenance and performance issues are caused by creating and growing technical debt. Primary way of fighting with the debt is having transparent definition of what standards, norms need to be fulfilled and work to be completed for each Product Backlog Item before we call it done. Of course this is achieved by transparent definition of Done which is taken very seriously. Product Backlog Item at the end of Sprint is Done or un-Done and goes back to the Product Backlog. Multiple Scrum Teams working on the same product will stick to the same definition of Done, so the level of quality will be consistent through the whole product. Cutting corners and lowering quality of work for speed happens when teams are pushed against unrealistic deadlines. In Scrum the Development Team estimates the size of work and collaborates with the Product Owner on forecast for Sprint. Therefore, in Scrum the Development Team estimates what can be done keeping the quality on the same level. When there is high pressure on delivery people have tendency to pay less attention to processes and standards. That is one of the reasons why is Scrum we have a role of Scrum Master responsible for understanding and enacting practices and rules. The truth about speed in Scrum We went through reasons for coming up with idea of low quality in Scrum. We explored the idea of quality. But still, where is the speed coming from if not lowering quality and cutting corners? Releases are late due to delays caused by late integration, late testing and bad communication. Cross-functional teams working in Scrum reduce and even completely eliminate the need for work products handovers. Focus on delivering potentially releasable product Increment each Sprint encourages early and often integration usually implemented in form of continuous integration practice. Stakeholders, Product Owner and Development Teams are closely collaborating, which gives short feedback loops and short communication lines. And remember Scrum is not a way to deliver fixed scope faster, but to deliver more value more often in the most optimal way.