{"id":9258,"date":"2019-09-05T15:54:52","date_gmt":"2019-09-05T18:54:52","guid":{"rendered":"http:\/\/blog.plataformatec.com.br\/?p=9258"},"modified":"2019-09-30T10:11:19","modified_gmt":"2019-09-30T13:11:20","slug":"how-to-manage-deadlines-in-agile-environments-get-to-know-the-reality-check-tool","status":"publish","type":"post","link":"http:\/\/blog.plataformatec.com.br\/2019\/09\/how-to-manage-deadlines-in-agile-environments-get-to-know-the-reality-check-tool\/","title":{"rendered":"How to manage deadlines in agile environments? Get to know the Reality Check Tool"},"content":{"rendered":"\n
TL;DR: The Reality Check is an agile tool designed to check if a deadline is feasible given the project context<\/strong>. It works by formulating a hypothesis<\/strong>, which can be updated every week by the technical team, where we organize our demands and the weeks before the delivery date. It only requires a simple board – physical or virtual. This tool is an alternative (or complement) for Burnup charts, Monte Carlo simulations, schedules, or other practices and techniques.<\/p>\n\n\n\n In 2017 I was working on a project to release a new product for our customer. The team had many challenges, including an aggressive deadline. The reason for such a tight deadline was simple: the customer expected to deploy the new product in an opportune moment in Brazil because of changes in the financial scene.<\/p>\n\n\n\n When will the team deliver the next feature? When will the project be delivered? Will the deadline be respected? These are examples of questions the team had been received regularly.<\/p>\n\n\n\n We needed answers to those questions, but I didn\u2019t have any past releases of the product or techniques based on legacy data or statistics (for example, a Burnup Chart with predicted dates). I didn\u2019t want to build a schedule either. So, I asked for advice from some colleagues from Plataformatec.<\/p>\n\n\n\n Searching for ideas to resolve that situation, one of my work friends told me about a specific ceremony. This idea had been used in a similar condition in 2015, and I got interested. The practice consisted of putting all demands (such as user stories) on post-its and organizing them per week until the last before the deadline, forming a timeline.<\/p>\n\n\n\n They didn\u2019t have a name for this ceremony, so they chose \u201cReality Check\u201d, because it\u2019s used to verify if it\u2019s possible to meet the number of demands in that specific time range (considering other variables too, such as the size of the team, technical environments, dependencies with other teams or systems, etc.).<\/p>\n\n\n\n If you want to know more, you can read the blog post Bringing continuous improvements into your agile process: The Reality Check Ceremony<\/a>, written by my friend Lucas Colucci.<\/p>\n\n\n\n The idea seemed to be exciting, but in that situation, I was looking for something solid because it was necessary to keep the customer expectation aligned all the time.<\/p>\n\n\n\n So I thought: if I turn the ceremony into a tool, adding more features and practices? I built a board with our weeks, and the deadline for the first release (according to the expectation from the CEO and the Head of Products, both from our customer). I added other feature concepts to the board too, and I talked to some work friends to get more ideas. Finally, I showed it to the team, and we built the first Reality Check Tool of the project. Below you can see one real photo of the result (with blur to preserve the confidentiality of our customer):<\/p>\n\n\n\n The subtitles are missing, so I\u2019ll explain the details below. By the way, I drew that subtitle next to the tool so that all people could understand each part of the Reality Check. The details are:<\/p>\n\n\n\n The logic is simple: which demands we believe we will be able to finish in the first week? And in the second week? And in the third and so on. The main idea is to fill that timeline and check if it\u2019s possible to meet all demands before the deadline. It would be a hypothesis (save this word!), not a schedule or an estimate.<\/p>\n\n\n\n But how can we build the Reality Check Tool? Keep reading.<\/p>\n\n\n\n The Reality Check is an agile tool designed to check how much a delivery remains feasible given the project context. The central idea of this tool is to maintain alignment, giving visibility to the progress of the project and some predictability as to the date of delivery.<\/p>\n\n\n\n In my opinion, most often it\u2019s more relevant for the project to keep the delivery date expectations well-aligned than to accomplish a deadline initially forced for project delivery.<\/p>\n\n\n\n Anyway, if you can work without deadlines, and I hope you do, maybe you\u2019ll have a friendly environment and a great scenario to work on many product solutions. But, if you can\u2019t escape from one deadline, perhaps this tool will be helpful for you, your team, and your stakeholders.<\/p>\n\n\n\n I presented two talks in 2018 about the Reality Check Tool in S\u00e3o Paulo, Brazil, to show the local agile community my experiences using it. I wrote another blog post about the Reality Check Tool in 2017<\/a> but in Portuguese.<\/p>\n\n\n\n Firstly, you\u2019ll need to map the scope of the next delivery at some details level. Common examples:<\/p>\n\n\n\n Next, write all the items in post-its. If possible, these items need to be prioritized at some level too (ask your Product Manager to do this). Finally, find a location to maintain the board (your wall, for example). You can keep it virtually also.<\/p>\n\n\n\n Now, write each week before the deadline from the next delivery in post-its too. A typical question is: how long do I need to map? The answer can change because of the context, but it\u2019s a great space between 3 to 12 weeks (one quarter) \u2014 less than three is too much, and more than twelve can be a big mistake.<\/p>\n\n\n\n You can put more essential pieces of information in post-its too. Example:<\/p>\n\n\n\n The next step is to organize your Reality Check tool. Put all demands on the left side, and each week on top distributed horizontally. You can separate each post-it with the weeks using scotch tape (like in the real photo). You\u2019ll have a board like this:<\/p>\n\n\n\n It\u2019s important to emphasize the word project. Maybe it can be your whole project, or only one piece (a big delivery or a subproject, for example). Anyway, it\u2019s an effort limited by time.<\/p>\n\n\n\n The scope of your project can be categorized. For example, you can divide by front-end, back-end, and UX\/UI, or user stories from different systems, or in some way that makes sense for your team. You can do this by using different colors of post-its.<\/p>\n\n\n\n Now it\u2019s the most crucial moment. It\u2019s time to distribute demands in the timeline for the first time. For this, we have one golden rule: the idea isn\u2019t to have precision in item distribution on the board, but to identify if it\u2019s possible to achieve the goal if reality were to happen that way.<\/p>\n\n\n\n Each technical member from the team (developers, designers, quality analysts, etc.) can talk to create the hypothesis. It\u2019s common to be hard to do this in the beginning, but after the first demands, the team gains the ability to distribute all items in the timeline. Don\u2019t worry. There will be doubts, questions, and speculations about many things, such as time, team composition, technical uncertainties, etc. They all are very important, but at this moment we need to create a hypothesis (it\u2019s not a compromise)<\/strong>. Assume the necessary premises, respect the restrictions, and distribute the items on the board.<\/p>\n\n\n\n If the setting happens in the first week of the project, the distribution of the first demands can be individual (each person chooses one user story, for example, and put it somewhere on the board assuming that the demand will be finalized in that week). If it\u2019s an ongoing project, the team can start with demands related to development. Remember: the demands are placed only on the week they would end.<\/p>\n\n\n\n Some tips:<\/p>\n\n\n\n By the way, Scrum Masters, Product Owners, Project\/Product Managers, Agile Coaches, General Managers, etc. don\u2019t help distribute the items. The Reality Check is an agile tool from and for the technical team, but it\u2019s an excellent idea to have a facilitator.<\/p>\n\n\n\n During or after items distribution, all of the team will begin to notice if it\u2019s possible to finish the scope before the deadline. So, perhaps it\u2019s an opportune moment to negotiate the deadline or the scope. In one of the times when I used the Reality Check Tool, the customer asked us an enormous scope and showed the team their expectations regarding the delivery date. When the team built the Reality Check, we discovered that the period was enough to deliver 20-25% of the scope. It\u2019s excellent information for your customer when seen early in the project.<\/p>\n\n\n\n Your result will be similar to this:<\/p>\n\n\n\n This project has nine weeks, and the team started to build the Reality Check Tool in week four. Now we have the board ready.<\/p>\n\n\n\n If you arrived here, you know how to do a Reality Check in ceremony format. You can do it once and start again from the week you are if you want to repeat it.<\/p>\n\n\n\n But you can keep the board and transform it into a tool. For this, the first step is to choose which features the team needs to give visibility and to provide helpful information to make correct decisions.<\/p>\n\n\n\n I like to use features to show which items are a work in progress (WIP), blocked, week of the start of development, and are pending from third parties. For example:<\/p>\n\n\n\n After putting the features in post-its, the team can go to the next step: calculate the perception rate. That technique helps the team to evaluate the level of comfort to delivery scope until the deadline. It\u2019s an answer to the question: numerically, how much are we confident that it\u2019s possible to deliver this scope before the deadline?<\/p>\n\n\n\n Each member of the team gets one post-it and, anonymously, write their number from 1 to 4, where 1 means \u201cI\u2019m not very confident\u201d to deliver that scope before the deadline, and 4 to \u201cI\u2019m very confident\u201d with that hypothesis. After this, the facilitator gets all post-its and calculates the average. Finally, he shows the result to the team.<\/p>\n\n\n\n An essential tip: it\u2019s an opportune moment to discuss if each member of the team has many divergences between the degree of confidence. For example, why did a team member put 1, and others chose 4? Maybe they have different perceptions of the actual situation. If necessary, the facilitator can ask for each member to vote anonymously again.<\/p>\n\n\n\n The final number must be on top of each week of the Reality Check Tool. The objective is to observe that perception in the delivery timeline.<\/p>\n\n\n\n It\u2019s time to show how to maintain the Reality Check Tool using the same example. The team distributed all items on the board, placed the features, and calculated the confidence perception rate. Now we have this scenario:<\/p>\n\n\n\n The demand C2 is complete. The demands C1, A2, A4, B3, and C3 are in development (one is blocked). The team knows one pending issue from A3. The team puts tags in demands B3 and C3 because both started in week four. B1 and B2 depend on A4 and C1.<\/p>\n\n\n\n We have five work items in progress. The team believes they will finalize four demands in week four (the demand C2 is complete). B3 started in week four, but the team believes they will complete it in the fifth week. C3 only in the sixth week. This scenario is the original hypothesis.<\/p>\n\n\n\n The team works during this week, and in the next Monday of week five, they need to update the Reality Check Tool. Using the same techniques previously used, now we have this reality:<\/p>\n\n\n\n Only the demands C2 and A2 are finished if we compare them with the hypothesis of week four. C1 and A4 moved to week five. Now, the demand B2 is in week six, and we have five works in progress again. Besides that, the team transferred B1 to another week. We have a new demand too: D1.<\/p>\n\n\n\n Adding or removing demands are common, and the team needs to update the board in both cases when it happens. Finally, the team got another perception rate for this week, 0.1 less than last week.<\/p>\n\n\n\n It\u2019s an expected result of Reality Check Tool: every week we create a new hypothesis of delivery based on the reality of the team and of the project! But the team doesn\u2019t need to update the board only once a week. The facilitator can observe all days of the week and keep the Reality Check Tool updated. In the first workday of the week, the facilitator should gather the team to update the board and to find a new hypothesis.<\/p>\n\n\n\n Now it\u2019s the time for week six:<\/p>\n\n\n\n There are many differences between weeks five and six. The team delivered five demands, but without the demand A4 (it started in week four, was developed in the fifth week too, and transferred to week six). One of them is new: D3 (finished last week). In the moment of board update, the team had already delivered the demand C3. D1 is blocked. Finally, another perception rate: 0.7 bigger than last week.<\/p>\n\n\n\n At this moment, I believe you understood how we could maintain the Reality Check Tool, right? So, every week, the team updates the board and creates a new hypothesis to deliver the scope before the deadline.<\/p>\n\n\n\n But there isn\u2019t a unique way to sustain the Reality Check Tool. When the team perceives that it\u2019s not possible to deliver the scope until the date agreed originally, we have some other options. For example:<\/p>\n\n\n\n Imagine the same team keeping the Reality Check Tool. Now we have this scenario:<\/p>\n\n\n\n If you sustain the Reality Check like a tool, you can show the reality about what is happening in the project, giving visibility for the deadline to your stakeholders. Therefore, you\u2019ll always give a potential delivery date, and maybe the team can create a connection with your customer. Finally, the team can feel empowered to make decisions.<\/p>\n\n\n\n When the team has a deadline, I prefer to use Reality Check like a tool because it can give visibility to my customer. But, if the team doesn\u2019t have a date to deliver the scope or if the deadline isn\u2019t critical, the ceremony may be better to align expectations.<\/p>\n\n\n\n I have two more examples from different projects to show you, both from 2018. Firstly, a Reality Check used in ceremony form:<\/p>\n\n\n\n Now, two photos showing the first and the last week of the first delivery from another project (made virtually).<\/p>\n\n\n\n First week: Last week: Notes: some demands have a tag with the word \u201cbefore.\u201d These user stories are demands initiated before the construction of the Reality Check Tool. And below the days in post-its with the weeks, we have the word \u201call\u201d and other nomenclatures, such as \u201c-1 (-2)\u201d, \u201c-2\u201d, etc. This detail is to show when one or more people from the team are out in that week because of a specific reason (examples: vacation, sick leave, etc.).<\/p>\n\n\n\n Perhaps you think the Reality Check Tool is an agile schedule, or a Gantt Chart 2.0, or even an estimate. This tool has some similarities with these practices\/techniques, I agree, but it\u2019s different! Let\u2019s understand:<\/p>\n\n\n\n Finally, I think it\u2019s essential to comment about my experience using the Reality Check Tool. I used it in software development projects, generally in teams with squad format. In all situations, the teams used other agile practices too, such as framework Scrum, Kanban method, and flow metrics. In general, the teams were formed by 8 to 12 members (including all roles).<\/p>\n\n\n\n I have helpful tips to share if you decide to use the Reality Check Tool. Maybe one or more tips can help you and your team. Let\u2019s go!<\/p>\n\n\n\n In this Burnup example, the forecast for the next delivery is August 10 (most likely), September 21 (pessimist), or July 27 (optimist), all based on historical throughput data, but the Reality Check Tool from the team indicates July 13. In this case, somebody can ask about it and understand the opinion of the team in contrast to predictions from Burnup.<\/p>\n\n\n\n If you don\u2019t know about Burnup and throughput, I recommend you to read the blog post Why we love metrics? Throughput and Burnup charts<\/a>, written by my friend Raphael Albino.<\/p>\n\n\n\n I hope you have liked the Reality Check Tool. I\u2019d appreciate receiving suggestions, more explanations, and I\u2019d also like to exchange experiences. Leave your comments below.<\/p>\n\n\n\n Thanks for reading!<\/p>\n","protected":false},"excerpt":{"rendered":" TL;DR: The Reality Check is an agile tool designed to check if a deadline is feasible given the project context. It works by formulating a hypothesis, which can be updated every week by the technical team, where we organize our demands and the weeks before the delivery date. It only requires a simple board – physical or … \u00bb<\/a><\/p>\n","protected":false},"author":61,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"ngg_post_thumbnail":0,"footnotes":""},"categories":[1],"tags":[123],"aioseo_notices":[],"jetpack_sharing_enabled":true,"jetpack_featured_media_url":"","_links":{"self":[{"href":"http:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/posts\/9258"}],"collection":[{"href":"http:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/users\/61"}],"replies":[{"embeddable":true,"href":"http:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/comments?post=9258"}],"version-history":[{"count":8,"href":"http:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/posts\/9258\/revisions"}],"predecessor-version":[{"id":9286,"href":"http:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/posts\/9258\/revisions\/9286"}],"wp:attachment":[{"href":"http:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/media?parent=9258"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/categories?post=9258"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/tags?post=9258"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}The beginning<\/h2>\n\n\n\n
Evolving the idea: a new tool<\/h2>\n\n\n\n
<\/figure>\n\n\n\n
What and for what?<\/h2>\n\n\n\n
Building the board<\/h2>\n\n\n\n
<\/figure>\n\n\n\n
<\/figure>\n\n\n\n
<\/figure>\n\n\n\n
<\/figure>\n\n\n\n
Maintaining the board<\/h2>\n\n\n\n
<\/figure>\n\n\n\n
<\/figure>\n\n\n\n
<\/figure>\n\n\n\n
<\/figure>\n\n\n\n
<\/figure>\n\n\n\n
<\/figure>\n\n\n\n
Summing up<\/h2>\n\n\n\n
<\/figure>\n\n\n\n
Other real examples<\/h2>\n\n\n\n
<\/figure>\n\n\n\n
<\/figure>\n\n\n\n
<\/p>\n\n\n\n<\/figure>\n\n\n\n
<\/p>\n\n\n\nAdditional comments<\/h2>\n\n\n\n
Advanced tips<\/h2>\n\n\n\n
<\/figure>\n\n\n\n