Tag Archives: planning meeting

Listen to Experts but Trust Your Team Members

Posted by on 2012/01/08 No comments

Back when I was working in a project as a team leader, on a cloudy Thursday an expert took me aside to talk about the time reporting of one of my team members. He pointed out that the team member in question spent about 6 hours doing a certain task which he – the expert – could have done in 15 minutes. He insisted that I called her to account for the time spent on this task. It was an awkward situation, because I knew that she had worked hard all day – I sat with the team and I knew that she hadn’t spent more than 5 minutes away from the task -, but still I was unable to explain the huge difference. Practically, that task consisted of two sub-tasks and unfortunately I had no experience with either of them.

Instead of talking to her immediately, I chose a different option: I decided to gain some experience on the matter and see how much time it really took to finish that task. I needed to choose this way, because if I had confronted her with the feedback from the expert, I would have only been able to tell her what he told me, that is that the task should have taken only 15 minutes to complete. Instead, I wanted to understand the situation and be able to help her to be more effective next time – provided that the expert was right and her time had indeed not been well spent in this case. Additionally, I wanted to leave the expert out of the discussion, because he wasn’t part of the team, and I felt that these discussions had to be done face-to-face: no need for a third person, an outsider to be there.

I scheduled our discussion for the next Monday, and I spent the preceding Sunday afternoon with the task at home. I needed 2.5 hours to complete the first sub-task, but I felt that I had already gained the necessary technical experience in order to have a constructive discussion on Monday. I assumed that the second sub-task was an easy one considering her technical level, so I estimated half an hour for it, adding up to a total of 3 hours to complete the whole task. Read more »

VN:F [1.9.17_1161]
Rating: 8.3/10 (3 votes cast)

Introducing the Expectation Line in Scrum

Posted by on 2011/11/12 5 comments

Several weeks ago my colleague Tamás made an interesting point about our planning meetings: we always committed to an iteration backlog – we are doing an interesting combination of Scrum and Kanban, but not Scrumban -, but we never asked our product owner whether she was happy with our commitment. She said that she hadn’t been satisfied, but followed what Scrum said anyway - classic autopilot behavior. This got me thinking and I realized that during the last couple of years every product owner I met had this very same problem: scrum was new and it didn’t help them much, because before Scrum the business dictated the speed of the development, but after introducing Scrum the development slowed down and started to live its own separate life.

In order to understand why, first have a look at this typical iteration backlog lifecycle:

The first sprint is usually more successful than the second one, but after five or six sprints the number of delivered user stories stabilizes – in Scrum terms: the velocity becomes stable. I talked to different Scrum Masters from different organisations and they independently told me that after the teams reach this kind of threshold, no matter what the product owner says or does, they deliver exactly the same amount of user stories. This is the point when the team starts its own life and starts to dictate to business: no matter what the product owner‘s expectation is, she will get the same amount of user stories sprint by sprint. Which is somehow good, makes the development predictable, but the business is never predictable, on the contrary, it changes a lot. Since the outcome of the planning does not follow the expectations of the product owner – which is driven by the business – she starts to ignore Scrum and eventually she gives up and from then on she will just pretend to be a product owner, when in reality she will fall back to classic project management.

Read more »

VN:F [1.9.17_1161]
Rating: 10.0/10 (1 vote cast)

Guest Blogger: The Time-box Issue

Posted by on 2011/06/21 No comments

This is the first time in the history of my blog that I share the thoughts of a guest blogger. I introduced Kanban to my friend Peter (@keksz_i on twitter), who is very exited about Kanban and eager to learn more about it. Unfortunately, he had to participate in a less successful planning meeting…

The Time-box Issue

I just recently got familiar to Kanban – thanks to Zsolt – and I’ve started digging myself deep into Lean thinking. As a progress, day by day I am realizing more and more about the drawbacks of Scrum during my work. Hereby I’d like to share some of these small but rather important experiences.

We were at a planning team meeting. Our team was expected to commit 22-24 story points, based on the team’s velocity. We’ve already selected 18 story points of high priority stories from the backlog, but there was another 8 pointer “must to have” high priority story. Obviously, that could not fit to the sprint, as we would had 26 points with the 8 pointer. All other stories had lower priorities or they were not even estimated. How shall we proceed in that situation? We had a customer pressure to deliver to that story as well, but we could not, as it was a very high risk that we are not going to finish it by the end of the sprint. Basically we were in a time trap indicated by the iteration.

There were two possible solutions. One of them is to look after smaller stories from the backlog and fill the gap with them. Unfortunately, we haven’t had them. Even if we had had other stories to take, that solution wouldn’t been effective. Doing low priority things (stories, fixing low priority bugs, technical depth) just to fill the sprint instead of doing the real important jobs is really a waste. We definitely should not have done that.

We went for the second option: splitting the 8 pointer story to smaller stories. We were able to split it into two 3 pointer and a 5 pointer story. The first was a kind of preparation story for the epic with no testing effort. The other 3 pointer and the 5 pointer were the actual implementation stories including testing. By doing the splitting, we were able to commit to the two 3 pointer stories, having 24 points to work on in the current sprint and most likely having the remaining 5 pointer story in the next sprint. This looks much better for the first glance, but if we have a closer look we can realize that there is a huge waste. We had to do an estimation session to so the splitting, we doubled the testing effort where obviously we had overlaps and we had to prepare and demo it 3 times for the customer. In fact, the estimation numbers are also reflected the waste, as the overall complexity of the original epic became 9.

Using Kanban, all of these wastes would not arise at all. In Kanban, there is continuous delivery, there is no time box to fit. In Kanban, we would just pull the 8 pointer story, implement, test and deliver it at once. Without extra estimation sessions, without testing and demonstrating a half-functional story, without waste.

 

VN:F [1.9.17_1161]
Rating: 10.0/10 (1 vote cast)