[vc_row][vc_column][vc_column_text]\u201cCan’t we rest for 1 Sprint?\u201d Does that sound familiar? Unfortunately, many teams that have been working hard for a long time are asking this question or they at least think about it even if nobody wants to express it. The statement \u201cI don’t think we should get jobs above capacity\u2026\u201d uttered by the coaches, Scrum Masters or some team members in the first Sprints that start with excitement and determination gets lost in the depths of the outer space. I think the most crucial question here is: \u201cWhat is capacity?\u201d<\/p>\n
More often than not, team members take jobs as they think that they could \u201chandle it\u201d, assuming that they can use all the time that is left in that Sprint. For example, let\u2019s say the speed of the team is average of 50 Story Points based on the previous Sprints, then comes this perfect dialogue:<\/p>\n
+ Let’s take that many jobs in this Sprint.<\/p>\n
– OK, but I\u2019ll be on leave for 1 day.<\/p>\n
+ I have 2 days of training.<\/p>\n
– I’m in a study group, count me out for 1 day too.<\/p>\n
+ Okay, let’s take a look at the jobs and we\u2019ll take them accordingly.<\/p>\n
(THEY COULDN\u2019T)<\/p>\n
They can’t because their perspective is different. The above dialogue is based on the man\/hour approach. Is this a wrong approach? No. As long as everything is stable, the man\/hour approach can be very consistent and logical. However, when you add the human factor into the complexity of the jobs, there is not such a stable environment. When so many extra jobs come out once you start to do one job, when everyone has different competencies and experiences, trying to calculate something over man\/hour is nothing but a great optimism. It is assuming that nothing will change, everything will proceed according to the most ideal plan. Everybody wants to think that Ahmet has as much experience as Bar\u0131\u015f and that he can do the job at the same time; Duygu will never get sick; Umut completed a similar job in a very short time before, so now he can do the same again; but things do not work like that in real life.<\/p>\n
This dialogue is actually the result of wanting to relate the effort of the job directly to the time out of habit. Is the time insignificant? Of course, it is one of the most important factors but only ONE OF THEM. Therefore, when using methods such as Poker Planning, T-Shirt Sizing; the factors such as the complexity, uncertainty, experience level, dependency of the job are also taken into consideration as well as time. So, \u201cTeam Speed\u201d \u200b\u200bis not just time. That’s why we do not make plans that will use the Sprint time until the last second, but we make plans that leave a buffer time in line with the team’s capacity. Buffer is a term that is interpreted differently by everyone, but I think it is the time for jobs that cannot be foreseen. If it is something we know, we write it down and show it (see Transparency). If not, that job is doomed to disappear into the Buffer black hole before it can be seen. This is the starting point of the \u201cSprint Fatigue\u201d concept. The part we call Buffer is the time period where you can read, breathe, and do things to improve yourself, as well as get the unforeseen jobs done. If you spend this time for jobs that are already seen clearly and planned to be done, it is natural that you say, \u201cCan’t we rest for 1 Sprint?\u201d<\/p>\n
<\/p>\n
Duygu Balc\u0131<\/strong><\/p>\n Agile Coach & Trainer<\/strong>[\/vc_column_text][\/vc_column][\/vc_row]<\/p>\n","protected":false},"excerpt":{"rendered":" If not, that job is doomed to disappear into the Buffer black hole before it can be seen. This is the starting point of the \u201cSprint Fatigue\u201d concept.<\/p>\n","protected":false},"author":4,"featured_media":57872,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[34,21],"tags":[],"_links":{"self":[{"href":"https:\/\/old.acmagile.com\/en\/wp-json\/wp\/v2\/posts\/57990"}],"collection":[{"href":"https:\/\/old.acmagile.com\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/old.acmagile.com\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/old.acmagile.com\/en\/wp-json\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"https:\/\/old.acmagile.com\/en\/wp-json\/wp\/v2\/comments?post=57990"}],"version-history":[{"count":0,"href":"https:\/\/old.acmagile.com\/en\/wp-json\/wp\/v2\/posts\/57990\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/old.acmagile.com\/en\/wp-json\/wp\/v2\/media\/57872"}],"wp:attachment":[{"href":"https:\/\/old.acmagile.com\/en\/wp-json\/wp\/v2\/media?parent=57990"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/old.acmagile.com\/en\/wp-json\/wp\/v2\/categories?post=57990"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/old.acmagile.com\/en\/wp-json\/wp\/v2\/tags?post=57990"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}