Effective Retrospectives & Reviews: A CSP’s perspective on continuously improving both the process and the product.

By Marco Mulder

Continuous improvement is a key principle of Scrum. Yet, though most Scrum teams conduct a sprint review and a retrospective at the end of each sprint, too many teams fail to implement the improvements they identify. In my experience, there are two common causes for this:

• Teams don’t have or maintain explicit standards for their product and process;

• Teams don't use the product backlog to schedule improvements.

Set a Dynamic Standard

A definition of done in Scrum defines general acceptance criteria to which all implemented features should adhere. This ensures that everyone has the same understanding of what it means for a feature to be “done.” Team members must all know these general acceptance criteria so that they know when they’re finished. The product owner and stakeholders need a definition of done so that they know what they can expect from the features delivered by the team. That does not mean, however, that the initial definition of done is the one you will want to use throughout the project's lifecycle. In fact, one of the reasons why an explicit definition of done is important is that it not only says what will be included in each feature, it also makes explicit what is not included. Some of the things not included may be planned additions later in the project.

Continue reading this article.

Power of the Post-it

By Aaron Conoly

When it comes to Scrum, I'm a newb. I got my CSM certification last year and have been slowly learning how best to introduce Scrum to my organization. Recently, I started using Post-its to enhance how we use Scrum.

Just to be clear, I am not the official spokesperson for 3M products (although that doesn't sound like a bad gig; in fact, 3M, if you're reading this, call me!), and I haven't received any kickbacks for endorsing the Post-it (again, 3M, call me!).

Anyway, I'm something of a hero around the office, because I solved two problems with a simple, yet extraordinary item, the Post-it. A year ago, we were up to our necks in missed deadlines, broken promises (and, at times, dreams), and shoddy workmanship. So, we decided to seek out a new way of getting things done. It so happens that we came across Scrum, which, incidentally, focuses heavily on getting things DONE. And, even though we aren't a software company, we were drawn to Scrum because it provided a fresh, effective way of producing acceptable product. After doing more research, we decided to send one of us to a CSM course. The next month, I spent two days learning about Scrum, and at times, nodding my head and pretending to understand conversations about "Java software architecture," and "version control systems." Later, I took the exam and got certified. I returned to the office triumphant, a veritable Jedi Master of all things Scrum.

Then my boss asked me a terrifying question. "Well," she said, "what now?" After stumbling and bumbling over how exactly to say let me get back to you on that one, I retreated to my desk, defeated. Suddenly I wasn't a Jedi Master, heck, I could barely pass as a Scrum Ewok. I had to find a way to confidently describe Scrum and how our company could use it to get better results.

I stressed until I remembered a great part of my CSM class. The instructor asked us to write down any questions, preconceived notions, or concerns on a Post-it and attach them to the wall. Later, if any of the questions or concerns hadn't been addressed, the instructor would read the Post-it and provide clarity. So I decided to use this approach. I called a meeting with my boss, the VP of my department and my colleagues to discuss Scrum.

"Ok," I said, "before we start, write down any questions or concerns you have about Scrum on a Post-it and stick them on this whiteboard." The room grew eerily quiet. After what seemed like an eternity, my boss finally stood up and put a single Post-it on the whiteboard. It said, "What is Scrum?"

This was my first experience with Post-its, and I was already willing to scrap them and Scrum all together. But, I don't give up easily, and I realized that they couldn't have had any concerns or questions, because none of them knew anything about Scrum. It was my job to lead them.

After explaining Scrum, and answering a few questions, the meeting ended. My boss approached me and said, "This sounds great. How do we make sure everyone's following the process?" We determined that I would be my department's ScrumMaster, and that part of my job would involve providing a visual that would help keep everyone on track.

So, I decided to give the Post-it another try. I wanted to provide a compelling, easy way for our team to keep up with our product backlog and track progress. So, after researching various approaches, I decided to get a large dry erase board. I listed all of our projects on the board, and created two columns, Current Sprint and Backlog. That way, every Sprint, our Team could add Post-its for things they were working on, and the PO could add Post-its to the backlog as new items were added.

The Post-it board immediately became a hit. You could say it was our second water cooler. I always find team members discussing new backlog items, or proudly announcing they've completed an item. Better yet, the team has a greater sense of accomplishment, as completed items get sent to a special place, the Wall of Fame, where a mountain of Post-its are proudly displayed (this was initially a molehill).

The Post-it has expanded its influence. Soon after starting our Daily Scrum, we decided to clearly identify the chickens and pigs, by providing "Cluck, I'm a Chicken," and "Oink, I'm a Pig" name tags. All visitors are required to wear a chicken name tag, which usually leads to a discussion about Scrum. Thanks to the name tags, more departments are learning about Scrum and asking more questions about the process.

We also use Post-its to encourage proper lines of communication. Unfortunately, and don't think I haven't tried at least twice, I don't have my own clone to run around and ensure our team is focused like a guided missile on their Sprints. So, everyone's cubes/office door has the "Have a request? Go talk to our ScrumMaster!" Post-it. This again has led to further discussions about Scrum, and we've ensured that all requests are getting properly funneled to the product owner.

So you could say that Scrum has changed the way we do business for the better, but it couldn't have happened without the Post-it (3M, I just sent an e-mail to your PR department. Call me!). These days, the Post-it continues to not only facilitate current processes; it is helping build a foundation for future projects. We just created a Strategy Board, a whiteboard that is separated into two sections, "Where We Want to Be," and "How Do We Get There?" Post-its already cover it.

For those of you thinking If you love Post-its so much, why don't you..., well, I just might do that.

And for those of you who have used the power of the Post-it in your Scrum processes, tell me about it. We're always looking for fun, new ways to better use Scrum.

Beware of the Evil “85% Done”

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.”

Scrum In A Nutshel

By Dan Rawsthorne and Douglas E. Shimp

Scrum is about Teams producing Results in an agile way. Scrum Teams achieve results anyway they can by using a simple set of rules to guide effort. We will describe Scrum as a simple applied model so that a central understanding of Scrum can be built. Other complexities of applied Scrum such as scaling, distribution, etc. will be explored elsewhere.

The Team

The fundamental element of Scrum is the Scrum Team (or "Team"), which is a small (usually fewer than ten) group of people that provides useful Results/Products for Stakeholders.

Arguably, the most important role involved in Scrum is the Stakeholder, as the Stakeholders are the ones who have desires, wants, and needs, and are the reason the Team is developing the software in the first place. Often, there is a special Stakeholder called the Business Owner, who actually controls the budget for the Team. The Business Owner is often the one who called or asked the Team to form.

While the Stakeholders are the most important source of validation for the project, the most important person on the Scrum Team is the Product Owner (PO). The Product Owner works with the Stakeholders, represents their interests to the Team, and is the first person held accountable for the Team’s success. The Product Owner must find a result that will satisfy the Stakeholders’ needs and desires. The Product Owner provides direction and goals for the Team, and prioritizes what will be done.

The Scrum Team Members, including the Product Owner, are the people who actually do the work that satisfies the goals and priorities the Product Owner has set for them. The Product Owner must work with the Team to find a rate and direction that the Team can go, to achieve a desirable result. Each Team Member is accountable to the rest of the Team for his/her performance, even as the Product Owner is accountable to the Stakeholders for the Team’s performance. The Scrum Team is cross-functional; that is, people on the Team (collectively) have all the skills necessary to do the work (analysis, design, code, test, documentation, marketing plan, drawings; whatever is required for the desired outcome). The Team is self-organizing, self-managing, and constantly trying to improve; they work on the priorities the Product Owner has set. The Team Members commit to the amount of work they can do without undue influence from the Product Owner.

In order to aid the Team (Product Owner included) in doing its work, there is a role on the Team called the ScrumMaster (SM). The SM's responsibilities are to be a facilitator, moderator, and coach, with particular emphasis on helping the Team mature its self-organization and management. The ScrumMaster manages the relationship between the Product Owner and the rest of the Team, and facilitates removal of impediments for the Team, often working with the Product Owner, the Business Owner, and other Stakeholders to do so. Impediments can come from within the Team and outside the Team. The ScrumMaster understands the Scrum process and how the Team is using it, recommends process improvements, and assures that the Team is following the process they have agreed to. If the Team does not follow its process this becomes an impediment. Most impediments can be addressed by simply causing them to become a center of focus. The SM stimulates that center focus by calling attention to the impediment. Creating a smart center of focus is the art of being a SM.

The Backlog

A Scrum Team's work is managed with a Product Backlog ("Backlog"), which is a prioritized list of Product Backlog Items ("PBIs," "Backlog Items,” or simply "Items"). When the list is small it is just a straight list of things, but as it grows we add grouping mechanisms to organize many little things and help us keep track.

These Items represent the Stakeholder's needs and wants – each of them is a request for something of value from the Scrum Team. These requests can be for anything, including software functionality, marketing, non-functional requirements, technical and infrastructure requests, business support, maintenance of existing systems, and so on. It is a rule of Scrum that the Team shouldn't do anything for any Stakeholder unless it's on the Backlog. The Team will be actively working on the top few Items of the Backlog during the Sprint; this part of the Backlog is called the Sprint Backlog, which is often thought of as a separate list of its own. The Product Owner is responsible for prioritizing that Backlog and thus, creating a distinction between the Sprint Backlog and Product Backlog. From the Team’s perspective, the Product Backlog is work that we might do some day, and the Sprint Backlog is work we are committed to doing.

The Backlog contains Items at all levels of fidelity, from vague wishes/wants/needs to finely detailed requirements. The higher the priority of the Item, the more detailed the request should be, so that it will be ready for planning and execution. Note: “ready” does not imply excessive detail but, instead refers to enough detail. The Team working with the PO will determine what “enough detail” is.

When a Scrum Project starts, the Product Owner should initiate the Backlog by working with the Stakeholders and other Team Members and capturing their needs, wants, and requirements as Backlog Items. As the Project progresses, the Product Owner and the Scrum Team should continuously work with the Stakeholders to (re)prioritize the Backlog, identify new Backlog Items, eliminate noise, and refine and generally clean the items list to get it ready for planning. The project effort will result in product that will often clarify and identify Backlog Items. This process is called Backlog Grooming, and is a continuous process throughout the Project.

Now that we have the notion of the Backlog to work with, let's describe the process, which involves discussion of both Releases and Sprints.

The Release

The goal of a Scrum Team is to produce and release results that meet the goals and priorities that have been set down by the Product Owner (hopefully as a result of working with Stakeholders).

Typically, before a project formally begins, there is a Visioning phase (this could also be the first phase in a project), when the Business Owner, Product Owner, and the Stakeholders produce a Product Vision and a Product Roadmap. The Vision provides the overall focus for the Project, while the Roadmap gives guidance about Releases and their Goals.

The Scrum Team’s purpose is to create a result that satisfies the Stakeholders’ needs, wants and desires, often so that more demand for their services is generated. This production is done through a series of relatively short, fixed-length iterations, called Sprints, in which results are produced by working on Items. The Sprint length can vary, but this requires more discipline on the part of the Team and is not advisable for new, less mature teams. The steps of a Release are relatively simple, and I'll describe them here.

Usually, the first thing that happens in a release is Release Planning. The Stakeholders, the Product Owner, and possibly other members of the Team, get together and negotiate what will be accomplished in the Release. This negotiation considers the Product Vision and Roadmap, balances the needs and wants of the Stakeholders against the abilities of the Scrum Team, and results in a set of Release Goals and a Release

Strategy to achieve them. The Product Owner and Team must update the Backlog so that there are prioritized Items on the Backlog that support the Release Goals and Strategy and are ready for planning.

Once we have a Backlog that supports the Release Goals and Strategy, the Team starts sprinting. The idea is for the Team to do as many Sprints as the Release Strategy calls for, and then Release the Results. Each Sprint looks basically the same, with the Release activities as part of the last one.

The Sprint

The fundamental process flow of Scrum is the Sprint, which is a relatively short period of time in which Backlog Items are converted into Results.

The first thing to do in a Sprint is Sprint Planning. In Sprint Planning the Product Owner works with the Team to negotiate what Backlog Items the Team will commit to for the Sprint in order to support the Release Goals and Strategy. Each of these Items has an agreed-upon definition of "Done," and collectively these Items are called the Team's Sprint Backlog. It is the ScrumMaster’s responsibility to ensure that the Team commits to a realistic amount of work, and that the Product Owner does not unduly influence this commitment. Often, the Items on the Sprint Backlog are tasked out in order to give the Team confidence that it can complete the Item, and thus commit to it. The tasking of Items can help the Team mature by paying attention to the work agreements they make with each other. The tasking can also help the SM detect when the Team is working well.

Once Sprint Planning is over, the Team begins work in the Sprint. The Team self-organizes to do the work and self-manages as it does the work. The Team’s work pattern is described as a swarm to get the job done. Team swarm is a pattern of performing Teams that looks like a swarm to an observer. While the Sprint is in progress, the Team will have Daily Scrums in order that each Team Member understands what the Team's status is. This allows the Team to detect when to adjust in order to be as effective and efficient as possible. These adjustments often take significant time and occur after the Daily Scrum.

During the Daily Scrum, and continuously throughout the day, the Team Members notify the ScrumMaster of any impediments they encounter. It is the ScrumMaster’s responsibility to facilitate the removal of these impediments. Often, this requires working with Team Members, the PO, the Business Owner, and other Stakeholders.

The ScrumMaster must also ensure that the Team does enough Backlog Grooming in order to be prepared for the next Sprint's planning meeting. The Backlog Grooming is a strategy to prepare enough work to begin next so that a rhythmic flow of work can happen.

When the Sprint is over there is a Sprint Review, when the Product Owner and the Team show the Team's Results to their Stakeholders. This is done for two reasons: to prove to the Stakeholders that the Team is moving in the right direction, and so the Team can get feedback on what they've done. If necessary, the Release Goals, Release Strategy, and Backlog are updated as part of the Review (or soon thereafter), considering the Review and any "business reality" changes the Stakeholders may have. When Teams are small they can rely on more intuitive reasoning to determine what the "right direction" is. As a Team grows they will see a need for more sophisticated techniques that use metrics to help them answer what the "right direction" is.

After the Sprint Review, the Team has an internal retrospective to analyze its performance and process. The Team decides what changes, if any, they wish to make to their process as a result of this analysis. These changes will be "enforced" by the ScrumMaster in future Sprints. To enforce something the SM will need to shift the focus to the issue at hand and then let the Team react. Telling the Team what to do is not desirable. Shifting the Team focus and thereby enforcing change is an art of the SM.

At this point the Sprint is complete, and the Team either begins the next Sprint, the next Release, the next Project, or disbands, as appropriate.

Quick Summary

Team of 7±2 does the work
PO provides the work requests
SM provides care for the whole team (PO/Team)
Team swarms on the work
Team is cross-functional
Team owns its process
PO provides validation for each work request
Work is done in short bursts < 30 days each (Sprints)
Work starts and stops with Planning and Review
Review demo for product; Review retro for process
Daily Scrum detects any adjustments needed
PO determines priority as a flow of work requests
SM observes and helps the whole team adjust
SM tunes the whole team for maximum performance

Five Scrum Short Stories

By Marko Majki

When I was first introduced to Scrum, I thought "What an easy and beautiful way to be efficient!" After years of doing Scrum, I found that it’s not that easy. It was easy to learn. And, as many times before, “easy come, easy go” was true. It was very easy forget easily learned facts of Scrum. I’ll tell you about some of the traps me and my friends experienced during Scrum implementation. Solving these was more or less successful, but if you recognize at least one of them in your environment, which you weren't aware of before, my article was a success. I will tell you five real stories about people who were on the edge of Scrum and how they succeeded in avoiding Scrum traps. My Scrum heroes' names have been changed to protect their identity. Let's begin.

Proxying Product Owner

"Beware of the ScrumMaster who thinks that he can permanently assume the Product Owner role," I would say. I've heard a similar saying before, "A good ScrumMaster can handle two teams and a great one can handle only one." If you try to do the ScrumMaster and Product Owner role at the same time, you're doomed. You won't be able to perform both roles correctly – that’s certain.

One day, Scott was told at the very end of a Sprint that the Product Owner on the project had to move to another project that had stalled. He was told to act as Product Owner proxy for some time. Scott and the team were in a highly dynamic and quickly changing business, and it was a pretty tough period for the team. The first issue Scott was facing was time. The Sprint was one week long, and he did partially succeed in resolving impediments and barely succeeded in preparing acceptable user stories during the first Sprint. The second Sprint was a total disaster. Impediments started to pile up, and Scott didn't succeed in preparing acceptable user stories. The Product Backlog was filled with a few essays, without good, smaller user stories. And Scott was a pretty good problem solver. He would have certainly been a great Product Owner, if he was focused only on this role. Simply, Scott didn't have enough time to do both roles well for the team. Another issue Scott experienced was context switching, but maybe this is the wrong term. A better term is perspective switching. That was very stressful. At one moment Scott was trying to solve impediments and at another trying to figure out which story would return the investment in the best way. How did Scott deal with this? He didn't. He told the stakeholders to delegate a new Product Owner. Even a non-experienced Product Owner is a better solution than a ScrumMaster acting as Product Owner proxy. Luckily, Scott's Product Owner returned and he was able to keep Scrum on the track.

ScrumMaster as a Team lead

Claire had a pretty strong technical background on system administration, networks, and Java software architecture/development. Top management considered this to be a great asset to the team she was supposed to serve as a ScrumMaster. Because top management had a foggy understanding of Scrum, Claire was considered to be a “Team Leader.” Claire was the most experienced programmer in this team, but didn't even have the role of developer. The other team members were really great developers and quick learners, but new to Scrum. They didn't quite understand the nature of her engagement in the project, even though she had tried to be pretty clear about her role. They knew Claire before this project and had respect for her as a developer. I suppose they expected her to deal with technical issues using her remarkable experience. This asset started to become a great burden for the team and for Claire personally. She knew that if she got deep into coding she wouldn't be able to act as a good ScrumMaster. The first Sprint Planning Meeting started, but when technical debt was discussed, everybody looked at her, expecting her valuable opinion. She remembered something that she heard once from a more experienced Scrum Coach. She asked the team to excuse her for some time and to continue the technical discussion without her. They were surprised, but after she left, they did continue. After some time she returned and they barely noticed her. She was satisfied with the result. When the meeting was finished, she asked the team if everything was ok and how they decided to address technical solutions. Everything was fine and the team was satisfied because they handled everything themselves. She suggested that they would feel better if they made decisions on technical stuff, and that they were very good developers. “Of course,” she said, “I'll give suggestions if needed, but I'm not supposed to make decisions. The team has the power to decide. My job is to serve the team and to be sure that the project and work are running smoothly.” Claire made an "impediment list" sticky note on the wall and asked the team to give her tasks whenever they wanted, no matter what issues they might have. Then they really understood her role on the project.

Support Departments Don’t Use Scrum

Robert was a Scrum Coach for a software department that developed in-house projects. They had used Scrum for almost a year, and were doing a great job. When Robert came to the company, the department was pretty messed up, but in a few months everything fell into place and the teams became hyper productive. This was recognized by top management, teams were regularly awarded, and everything was fine. But Robert was a little worried. At first, he was focused on the teams, and wasn't able to see the whole picture. Using Scrum, real issues were surfacing, but he was focused on the issues he had influence over, and the team was solving them. So, when impediments inside the department were minor, other impediments became visible. The first sign of trouble was that the Product Backlog was pretty empty. He talked with Product Owners and discovered that they couldn't get enough information to create acceptable user stories. “Why?” he asked. Simply put, nobody from other departments had the time to define what they needed, and when they needed some functionality, they needed it immediately. From his perspective, communication with other departments was an impediment, but he felt responsible to initiate the solution. Now, because teams were pretty self-organized and doing well, it was time to spread Scrum to the other departments. First he talked to top management about the situation in other departments and presented the idea about introducing Scrum. They hadn’t originally considered it, but were pretty satisfied with the re-organization of the software department, so they agreed. Robert explained that he didn't want to make this transition top-down, but would try with volunteers. He invited heads of each department to a working breakfast and explained Scrum, presenting potential benefits for the department using its principles. He asked them to bring a few team members to the next three meetings about Scrum. They were pretty shocked when he introduced some of the Scrum games, expecting a PowerPoint presentation. “Hey, you didn't even bring your laptop,” they said. “I don't need it,” Robert replied. After playing two games, he conducted a practice retrospective meeting, allowing the teams to reach their own conclusions. Then he helped them to make parallels with real situations that they were dealing with. It was quite refreshing and revealing for most of them. Then, he explained that Scrum was not a silver bullet, but a tool that could help them to understand the impediments and to enable them to work better. He asked them to consider it and to let him know if they would like to try Scrum in their environment. The next day, the chief of the technical support department contacted Robert, claiming that his team was overwhelmed and eager to try Scrum. "Great!" Robert said. "Let's start preparations for our first Sprint."

Disputed Definition of Done

Ulrich was a pretty experienced Scrum Practitioner. He knew that coaching a new team was going to be tough. They were all experienced programmers, but new to Scrum. Initially, coaching was tough, with much resistance and conflicts; a bumpy road that was now almost behind him. Eventually, things were much smoother because he knew the team's velocity and the team knew their velocity, which was much more important. Velocity was regarding to “DONE DONE” user stories. He remembered the issue the team had with this, their definition of done (DoD). As he explained at the very beginning, the team and the Product Owner had to reach an agreement on this. One of the guys came up with a DoD proposition, and the team and the Product Owner were ok with it. One of the items in this list was "unit test coverage of 80%." After the first few stories were "done," he asked the Product Owner to test the items from these stories. With the tool they had, it was easy to see a unit test coverage of 23%. Ulrich asked the Product Owner what he thought about that. He answered that he wasn't satisfied with that the result. "Why?" asked Ulrich. "Because these stories are not done," replied the Product Owner. "Do you need a unit test coverage of 80%?" asked Ulrich. "No, I don't know why they chose these figures, but if the team defined these, I expect them to meet these criteria," answered the Product Owner. And he was right. The Sprint ended the next day, and during the Sprint Retrospective, Ulrich announced that the Sprint had failed, which provoked a very emotional response from the team members. He explained the reason and showed them real figures on test coverage. "But why is this important? We did all the necessary tests. We didn't want to waste time unit testing trivial methods, such as getters and setters, and we didn't want to test something covered in integration testing," screamed the guy who purposed the DoD criteria. "Yes, you are completely right, but you promised something about unit testing and this was not accomplished. Could you tell me how you determined the proposed DoD?" Ulrich asked. "Well, I didn't know what criteria to propose, so I copied some from a Scrum blog, which looked great at this time." "Ok, guys," Ulrich said, "this is my failure as Scrum Coach as well and it's my fault that you didn't understand the meaning and importance of DoD. DoD is different from team to team and project to project. This is not a general standard that should be implemented in all situations. And Scrum is not a standard that can be implemented the same way in all situations. Those are tools, which help you make better software, but you need to involve your intelligence, energy and creativity to make it happen. Ok, let's do the job. Let's create a DoD acceptable to us and our Product Owner. You are experienced developers and you know everything about good programming practices. You've seen one of many possible DoD's. Let’s make new a DoD we can commit to."

Estimations in hours

Marianne was inexperienced, but passionate about Scrum. She started her first Scrum project with the team and was thrilled, anticipating her first ScrumMaster job. The team knew about Scrum and was interested in trying it. Before the first Sprint Planning Meeting, the Scrum team agreed on some conventions and one of them was estimating user stories and tasks in hours. This was the natural choice for the team and Marianne agreed with that. Estimating in user story points was awkward to the team, since they couldn't figure out how to correlate this to some real measurement unit. So they started their Sprint meeting and started estimating. They estimated all user stories and chose ones they could commit to finish until the end of Sprint. Then, the Product Owner stood up and spoke. "Well, guys, you just committed to finish user stories worth 230 hours and you have 400 working hours in your Sprint. Even if we add 30 hours for the meetings during the Sprint, still there's 140 hours in the Sprint you should commit to. Is my math correct?" "Yes, you're right," said the senior developer, "but a working hour cannot be equal to a development hour. We have to have time to think about the story, business process, architecture etc. So, coding functionality is not the only job we're working on. Development is the intellectual process, not an exact, simple operation. We really didn't underestimate, in my opinion, and we didn't want to „steal‟ some time. I just feel that we cannot commit to more than we already did." "Ok guys," continued the Product Owner, "I believe you were honest with the estimations and I think that this is a fine velocity if you meet those commitments with your definition of done. I just can't figure out this difference and it would be difficult for me to explain this to the stakeholders." It was good timing for Marianne to do some facilitation work. "The way I see it," she said, "we have a problem with the measurement unit. The Product Owner is satisfied with the features to be developed in this Sprint, but somehow user stories measured in hours don't provide the real information, correct? Furthermore, this difference in time is causing confusion. If developer hours cannot linearly correlate with real time, why don't we say points, not hours? After a few Sprints, we will be better in our estimations in these points, correct? And there will be no confusion with working hours and time. After a few Sprints, we will know our velocity in these points and will have more experience in estimating work. Stakeholders will get their graphics in these points and will be able to monitor progress daily. What do you think?" The Product Owner was delighted with this idea, knowing that he'd be able to show diagrams to the stakeholders in real time, and the team was relieved from the pressure they felt after Product Owner's speech. Marianne scored her first small victory helping her team to overcome its first impediment and potential conflict. After a few Sprints, they got used to estimations in user story points, so it came naturally to them.

I hope that you enjoyed these real Scrum stories and that you can recognize some of the situations in your everyday Scrum practice. Please comment on them and comment on how you would deal with these situations.

What is Definition of Done (DoD)?

By Dhaval Panchal

Definition of done is crucial to a highly functioning Scrum team. The following are characteristics that you should look for in your team’s definition of done. Verifying that your team’s DoD meets these criteria will ensure that you are delivering features that are truly done, not only in terms of functionality but in terms of quality as well.

DoD is a checklist of valuable activities required to produce software.

Definition of Done is a simple list of activities (writing code, coding comments, unit testing, integration testing, release notes, design documents, etc.) that add verifiable/demonstrable value to the product. Focusing on value-added steps allows the team to focus on what must be completed in order to build software while eliminating wasteful activities that only complicate software development efforts.

DoD is the primary reporting mechanism for team members.

Reporting in its simplest form is the ability to say, “This feature is done.” After all, a feature or Product Backlog Item is either done or it is not-done. DoD is a simple artifact that adds clarity to the “Feature’s done” statement.  Using DoD as a reference for this conversation a team member can effectively update other team members and the product owner.

DoD is informed by reality.

Scrum asks that teams deliver “potentially shippable software” at the end of every sprint. To me, potentially shippable software is a feature(s) that can be released, with limited notice, to end users at the product owner’s discretion. Products that can be released to end users with two days can be reasonably said to be in potentially shippable state. Ideally, potentially shippable is equivalent to the Definition of Done.

In reality, many teams are still working towards a potentially shippable state.  Such teams may have a different DoD at various levels:

• Definition of Done for a feature (story or product backlog item)
• Definition of Done for a sprint (collection of features developed within a sprint)
• Definition of Done for a release (potentially shippable state)

There are various factors which influence whether a given activity belongs in the DoD for a feature, a sprint or a release.  Ultimately, the decision rests on the answer to the following three questions:

1. Can we do this activity for each feature? If not, then
2. Can we do this activity for each sprint? If not, then
3. We have to do this activity for our release!

Chris Sterling recommends that for activities that cannot be included for a sprint/feature, teams should, “Discuss all of the obstacles which stop them from delivering this each iteration/sprint”

Common root causes for impediments include:

• Team does not have the skillset to incorporate activities into the definition of done for a sprint or for a feature.
• Team does not have the right set of tools. (Example: continuous integration environment, automated build, servers etc.)
• Team members are executing their sprint in mini-waterfalls.
  * Aha! Here’s an opportunity to be more cross-functional and share responsibilities across functional silos.

DoD is not static.

The DoD changes over time. Organizational support and the team’s ability to remove impediments may enable the inclusion of additional activities into the DoD for features or sprints.

DoD is an auditable checklist.

Features/stories are broken down into tasks both during sprint planning and also within a sprint. The DoD is used to validate whether all major tasks are accounted for (hours remaining). Also, after a feature or sprint is done, DoD is used as a checklist to verify whether all necessary value-added activities were completed.

It is important to note that the generic nature of the definition of done has some limitations. Not all value-added activities will be applicable to each feature since the definition of done is intended to be a comprehensive checklist. The team has to consciously decide the applicability of value-added activities on a feature-by-feature basis. For example, following user experience guidelines for a feature that provides integration point (eg: web service) to another system is not applicable to that particular feature; however, for other features within the system that dointerface with a human being, those user experience guidelines must be followed.

Summary

The definition of done is orthogonal to user acceptance criteria (functional acceptance) for a feature. It is a comprehensive checklist of necessary, value-added activities that assert the quality of a feature and not the functionality of that feature. Definition of done is informed by reality where it captures activities that can be realistically committed by the team to be completed at each level (feature, sprint, release).

Definition of Done: A Reference

By Mayank Gupta

An Agile project has ceremonies (sprint planning, release planning, sprint retrospective, etc.) and metrics (sprint & release burndown charts) designed to ensure that the project is in a healthy state. Unfortunately, many Agile projects fail even after following all the ceremonies religiously. Why? One of the primary reasons is that they are not able to deliver value to the customer at the end of each sprint. They deliver a product at the end of each sprint, but not a product that is potentially shippable. Here lies the root cause of failure. The software these projects deliver at the end of each sprint is half tested, half documented, half refactored and only half ready for release.

An explicit and concrete definition of done may seem small but it can be the most critical checkpoint of an agile project. Without a consistent meaning of done, velocity cannot be estimated. Conversely, a common definition of done ensures that the increment produced at the end of sprint is of high quality, with minimal defects.  The definition of done is the soul of the entire Scrum process.

Before we explore a definition for done, it is important to define another Scrum term: potentially shippable product.

Continue reading this article