By Marko Majkic
Years ago, in the dawn of my Scrum voyage, I was asked by my colleague from the sales department to estimate a project. The situation was kind of complicated; I would say kind of weird from the beginning.
The project was a web application, which was supposed to service about a thousand simultaneous users. The client was in another country, so we communicated only over Skype and e-mail. I got this estimation task in late January and was told that the application should be finished in a beta version by February 1, and a final version should be released on March 1. "Tight schedule, very tight," I thought. And we didn’t even have the team assembled because our developers were on other projects and pretty busy. So, we needed to gather the team, to find developers, and to finish the project (beta) in two weeks. "Pretty challenging," I told my colleague. He already had some contacts with a recruiter and told me that finding a "few programmers" wasn’t a problem. "Ok, let’s have an online meeting with the company owner," I suggested. So, we had the meeting. Apparently, they had started this project six months prior with just one developer. I thought this was interesting. A few days prior to our meeting, the developer told the client (“Jack”) that he had to leave the project for personal reasons. “Even more interesting,” I thought and smiled to Gary (my colleague from sales department). Now, the Client had promised the stakeholders that they would deliver the beta version in two weeks and the final version after a month. If they couldn’t deliver, they would have to refund money with penalties. So, Jack was ready to pay big money to have this project finished on time, and Gary saw a nice opportunity for our company. I saw an opportunity to show the power of Scrum, but I was a little worried that the team didn’t exist at that moment.
"Hey Jack," I asked, "do you have an idea what has been done and what is supposed to be done by our team?"
"No problem, I have an online demo," answered Jack, "and I reviewed the application thoroughly with our developer. He told me that application was 85% finished."
"This is great!" I said, "Why don‟t you release this version with all the completed functionality, and we can work on the remaining 15%! This way you and your partners would have a faster return on investment."
"No, no, you don’t understand," Jack told us, "We have all the functionality developed. The developer told me that each feature is 85% finished."
I was speechless. "Ok," I said, "so, you have a definition of done with seven items, and for each functionality, six items are finished and one remains to be finished, correct?"
"Errr…sorry, I didn’t hear you well,” answered Jack. "You were talking about some, definition of done,‟ right? What is the definition of done?" At this moment I was almost terrified. He didn’t have any idea what was done on the project.
I tried to be calm. "Ok, but how do you know that the project and each functionality was 85% done?"
"Well, the developer told me so," he said.
The good thing was that he had full confidence in this guy. I was pretty skeptical. I was interested to see what was really done on the project.
"Ok," I told Jack, "would you send to us some online demo info and a list of requirements, please? We will analyze this and get back to you with our estimates."
"Great," Jack said. I suppose that he was thinking we were already on the project. The work day was almost over and Gary and I decided to work until we had some estimates for Jack. So, we worked hard for the next four hours. I did estimates for programming work and Gary was testing the "almost finished" functionalities. I did optimistic (but still realistic) estimations. Gary was working on the functionalities list, comparing it with the online demo.
After the job was finished we had a conversation. Gary showed the functionalities to me, one by one. After each one, we were more and more worried. At the end we did a draft estimate of the developers‟ work needed for finishing the project. The best-case scenario was that, with a good team of experienced (read: more expensive) developers, the beta version could be deployed on March 15 and the production could start on May 1. This was an optimistic estimate. Jack’s (or developer’s) "85%" wasn’t 85% - but actually between 15% and 50%.
I told Gary, "Let’s drop all of it. We should do everything from scratch and do it right. Let’s suggest this to Jack." And by "right," I meant "in Scrum way." I knew that we couldn’t do a good job by continuing to work on the existing code. It was pretty messy; no tests, no code documentation, no basic documentation at all. And I was sure that we couldn’t commit to finish a beta version in two weeks. Not to mention that we didn’t have the team yet.
After four hours of working on the estimate and analyzing the project, we got back to Jack. I suggested to him to start from the beginning right away and told him that he needed to speak with the stakeholders. He didn’t like what he heard. “Hey, we need to go beta in two weeks. I don’t care how much it will cost. Add ten developers if needed!” he was upset; I could hear it in his voice.
I didn’t know about Brooks‟ law at that time, but I had some experience with adding more developers to a project, and I did explain to him that it would probably not solve the problem.
I suggested that the only way to make the project healthy and avoid failure was to get real, to present the stakeholders with the real situation, to accept responsibility, and to deal with it. We would help this project to succeed at a lesser cost than what they already had spent, and produce it three times quicker than they had planned at the beginning.
"No," he said, "my project is 85% done. I will find some other team that will finish it in time. Thank you for your time."
I was amazed. He was hypnotized by the evil magic of "85% done." I knew this project was doomed. And very soon, unfortunately, we could see that I was right. The website has never seen daylight.
Years after this experience, I faced the "evil magic of 85%" several times. We didn’t get this job, but I gained great experience from it. Whenever I heard that I should join/save a project that was in trouble and "85% done," I knew that something was wrong. Some of those projects I finished successfully and saved them. Some of them failed. But almost every time when failure occurred, people (top managers) were seemingly hypnotized, repeating "we‟re almost done!" I like Scrum, among other things, because it emphasizes a clear definition of done. A story is done or not done. There is no such thing as "almost done." There either is or isn’t business value, no matter what tasks developers have finished. There is no such thing as "85% done." And once again, I don’t mean 85% of all user stories. I mean 85% of each user story. By Scrum criteria, this means 0% of project. With 85% of all user stories "done done," I would probably go live with my application and would be very happy about that.
I was thinking about this evil magic of "85% done." Why is it so powerful? Here are some of possible reasons.
First, it makes us think we‟re almost there. “Hey, just one small effort and we‟re there.” This number gives us a comforting feeling that we can relax, because the job is almost done.
Second, this number is ideal, because it’s not too big – so in case someone wants to check the work, the missing 15% can be always be blamed on something not working – even if it is at the very beginning. This number is not small either, preventing someone from saying you are far from finishing the job. This evil number is perfectly chosen for its evil purpose – to keep us from establishing a definition of done and really finishing the story/project.
Third, this number is not quickly verifiable. You can say it and nobody could check if it is true, without getting deep in the code.
All in all, don’t trust a manager or developer who claims that 85% of a story is done. You can run away from these situations or you can use Scrum and a definition of done as powerful tools for fighting this evil and save the world (of the project at least).
And to all of you Scrum guys – don’t measure progress within the story. A story is done, or it is not done. Please, make a definition of done suitable for your project with your Scrum team and stick to it. Make your user stories small and doable in a Sprint. A user story is a measurement for the business value of your software. So, deliver done user stories, deliver complete business value, and, of course, don’t forget; beware of the evil “85% done.”
