One Day Tasks

It is quite difficult to identify a portion of work for one day. On the other hand it incredibly and surprisingly simplifies basically everything in the scrum. Let me try to explain...
Traditional tasks
All of us know them very well. You've got a story to show some data on the screen. It is quite natural to split it into back-end part and front-end part. So far so good. Naturally, you're going to start with back-end. It will need need any DAO, some service, couple of unit tests... The easiest thing that you can do is to create a task with description of "Implement back-end functionality" and estimate it by 3 days. Wait, 4 days would be more reasonable. As a bonus, you have now at least 3 days for saying "I' worked on my task yesterday and I'll continue working on it today" on stand-ups. Life is easy. Even the burn-down chart looks great as long as you log hours. All other members of the dev-team do the same and the ScrumMaster sees a nice chart every morning. But suddenly, right before the end of the sprint the burn down stops going down and looks like dead men's ECG. What happened? This guy forgot this on his general task (e.g. integration tests), that guy forgot that, other guys just underestimated something and now they all just updated remaining hours. ScrumMaster had an heart attack and now he tries to convince the dev team that the sprint goal is important and thus they're supposed to finish everything over the weekend. Everybody is annoyed. But they are not that bad team, they don't really want to hide behind their tasks and they like their ScrumMaster... So they did a retrospective and realised that they need more granular tasks. Like implement DAO, implement service, do uint tests... And they even agreed on a rule that maximum estimate of one task is 16 hours. Will this help? I'm not that sure...
The problem is that soon or later there will be basically atomic task (create service) but every developer will say that it is not possible to get it done in 16 hours. And now what? I say "play video games!".
Play video games
Video games have checkpoints. They are usually not very far form each other and after each checkpoint you can decide if you want to try to reach another one. They usually don't have linear complexity - there are tough bosses waiting for you  And the mission is not complete until you reach the last one no matter how many of them are already behind.
While a user story represents a shippable increment, a task doesn't. It is not necessary to define tasks as deliverables - they can represent checkpoints. The only problem is that it is much more difficult to see or identify checkpoints than clearly visible deliverables. It requires thinking. But I would bet that you already did it and maybe you're doing it every day. Have you ever said to yourself "I'll just finish this idea to see if it's working and then I'll go"? I did this many times because I don't like to go home with unfinished idea in my head. It keeps me thinking about it and I can better sleep when I know what is the point from which I can continue tomorrow. For example you want to be sure that the complex query in your DAO class is really working well in every case. Or you need to know that your algorithm builds correct tree when the whole solution is based on using a tree... You didn't finish the DAO or the algorithm but you reached a checkpoint. When you're implementing a service it definitely has an interface. Can particular methods be your checkpoints? A combination of them? You just need to ask yourself "What I want to get done today?".
Sprint planning in 30 minutes and 5 min stand-up
So after grooming the stories the team spent some extra time and identified checkpoints or one day tasks for couple of stories that will go to the next sprint. Now it's time to pick the fruit. One day tasks work perfectly with the scrum board. At the beginning of sprint planning the dev-team just creates stickers for particular tasks and put them on the board when the story is taken to the sprint and the task is assigned. Nobody needs to calculate remaining capacity for particular members because first everybody knows his capacity and second the overall capacity is given by the number of stickers where member's count times sprint days is 100%. Of course, there is always something wrong, something takes longer etc. so by experience it's a good practice to keep the number of stickers on the board somewhere between one half and three quarters of the maximum number. The sprint planning can be done in 30 minutes this way.
Scrum board with 1d tasks gives an ultimate view of the work status. It's simple. During the stand-up, each day each team member just moves his checkpoint sticker to the "Done" column or draw a dot on it if it was not done. The team can easily see if they still follow their plan... Instead of describing their work from yesterday they focus on why some checkpoints have not been reached and how to help each other. As a bonus, nobody needs to log hours or status into any system. The ScrumMaster sees everything clearly on the board and can do it in few minutes. Developers can focus on their work.
12/30/2016

Komentáře

Okomentovat

Populární příspěvky z tohoto blogu

Yesterday's Weather Rule

A legend says that there was a government that spent millions of dollars on a weather prediction satellite. After a big effort and long time they developed a thing that was able to accurately predict the weather with 70% success rate. It was quite good until somebody realized that if they simply said that today's weather will be the same as yesterday's weather they'd also have the accuracy of 70%. The idea is that you can predict what's gonna happen from what already happened. In the scrum process, this principle helps us to avoid overcommitting. The rule says "Don't take more to the next sprint than you delivered in the previous sprint". It can perfectly happen that the team cannot deliver the whole sprint commitment. But it is very important to take appropriate steps in order to keep this problem under control. And applying the yesterday's weather rule is the basic thing that you can do. Just reduce the sprint commitment of the next sprint to the ...
Další informace

Three Levels of ScrumMaster

Scrum defines three roles. ScrumMaster, Product Owner and Development team. While it is easy to understand the PO and dev team role, to understand the ScrumMaster role can be challenging even for ScrumMasters. ScrumMaters are building self-organized teams. But what ScrumMaster does when the team is already self-organized? Let's take a look at a concept of three levels of the ScrumMaster as it it described in the Great ScrumMater: #ScrumMaster Way book. Level #1 - My Team ScrumMaster at this level feels responsibility for his team. The goal is to build self-organized team and to let people embrace the agile mind set. It sounds easier than it is. As a beginner the ScrumMaster can be even struggling with questions like "How can I make myself useful everyday?". But the goal is a long-term activity and the SM should actually suppress the urge to do something, i.e. give advice, propose a solution etc... The first step for SM should be to make himself comfortable in observi...
Další informace

Tribal Culture and Leadership in Agile Environment

The concept of tribal culture in an organization was introduced in the book  Tribal Leadership . It is quite interesting theory and from the agile environment perspective it has a new and important dimension. Let's have a look and put things together.  A tribe is a group of people that have something in common. In an organization trying to set up agile environment, we can easily imagine a scrum team. But we also have the community - a team of teams. Then there are virtual teams like a team of scrum masters, product owners or managers. The whole business groups... We can identify tribes at basically every scale.  A tribal culture is the dominant culture that can be observed in a group of tribes. Or in an organization. The culture can be described as 5 stages. Let's explore these stages and then we will have a look at what it means for us. Stage #1 - Life Sucks A culture of individuals with no hope. Everybody is alone in such culture. This is a culture of prisons a...
Další informace