Scrum and SVO-P

By Dan Mezick

Scrum is unique in that the management method is consistently direct. All communication in authentic Scrum is concise, direct and clear. Scrum encourages responsibility. The daily stand-up meeting actively encourages personal responsibility to execute on specific work, and to be accountable to the Team. The three questions of Scrum are questions related to accountability for specific commitments.

Each of Scrum's three roles clearly defines responsibility for a set of specific tasks. For example, the Product Owner is required to gather requirements, place them on the Backlog, and prioritize them. The Team is required to pull the topmost N items from the Backlog to load a Sprint, to attend the daily Scrum, and so on. Each role in Scrum takes responsibility for a specific set of tasks. Scrum roles and ceremonies actively encourage responsibility.

Language directly influences thinking and perception. Syntax that is consistently direct encourages responsibility and clear thinking. Indirect forms of syntax can often obscure the subject and encourage the dodging of direct responsibility. Avoiding responsibility is in direct conflict with the Scrum values of Commitment and Focus. Indirect forms of verbal communication are therefore not in alignment with Scrum values. Indirect verbal forms do not support Scrum.

I believe that SVO-p can be very profitably incorporated into the Scrum framework. SVO-p stands for Subject-Verb-Object, Present Tense.

SVO-p is a syntax. It is a style of communication in which you always know who is responsible for an action. SVO-p is an active form that encourages clear thinking and candid, direct communication. SVO-p can help clarify your thinking.

Communicating in SVO-p requires definition of who is acting, what they are doing and to whom. It requires placing the thought in the present; that is, "in the now." Speakers and writers who actively dodge responsibility often choose the past tense and the future tense for expressing thoughts. Politicians, for example, often assign blame to past events, while making promises about the future.

SVO-p brings clarity to communication, and directly affects thinking through the constraint of language syntax.

Examples:

Non SVO-p

"The people who write articles for free are to be congratulated."
This sentence puts the congratulations out in the non-existing future and also hides the identity of the congratulator.

SVO-p

"I congratulate the writers who write articles for free."
This sentence in SVO-p identifies the user and places the action in the now.

Non SVO-p

"I've yet to meet anyone who has given me a straight answer."
This sentence places the action in the future and obscures the object of the sentence. It also places the giving of 'straight answers' in the past.

SVO-p

"People don't give me straight answers."In this SVO-p sentence, 'People' are acting on 'me' in the now, by not giving straight answers.

You may find that speaking in SVO-p is difficult at first. You may also find that the use of the SVO-p syntax can be contagious. When you use it, others often tend to naturally speak back to you in SVO-p.

SVO-p is particularly well suited for use during Scrum communications, because SVO-p is consistent and supports the Scrum values: Commitment, Focus, Openness, Respect, and Courage.

SVO-p discourages "passive voice." Passive forms tend to conceal the subject and avoid responsibility. This is a problem because of a much higher likelihood that the receiver of the message may misunderstand the statement. The use of active voice in the present tense supports immediate action in the present moment. The subject-verb-object form tends to support direct and clearly articulated responsibility.

Responsible action in the present moment is consistent with Scrum values. For example, in daily Scrums it is the responsibility of the ScrumMaster to make immediate decisions in the present rather than deferring decision-making into the non-existent future. Likewise, in Scrum there is an emphasis on learning empirically, in the present, while avoiding making any specific predictions about the future. In this sense, Scrum and SVO-p are a perfect match.

The use of SVO-p by Scrum practitioners actively supports the success of Scrum in the present.

I notice that Ken Schwaber and Mike Beedle, co-authors of the book Agile Software Development with Scrum, write in nearly 100% SVO-p. The entire book except for a small part is written in SVO-p. This makes total sense, because the SVO-p form is consistent with the beliefs, values and behaviors of authentic Scrum. It is therefore no surprise that the original and most experienced practitioners of the art of Scrum use SVO-p as the preferred syntax for communicating the essentials of it. SVO-p is a very natural, nearly automatic fit with Scrum.

When you start experimenting with SVO-p in verbal communications, you find that it is necessary to speak in simple and direct (SVO) terms. You find that speaking in the present tense keeps you in the now, and tends to clarify your thinking. SVO-p strongly supports an empirical approach to work and problem-solving by focusing attention in the present moment, and making perfectly clear who is acting, and upon what.

The use of SVO-p strongly supports the reception of interactive loops of Scrum feedback in the present. This property of SVO-p tends to support the reception of feedback over the development and acceptance of "predictions" regarding the non-existent future. The use of present tense focuses attention "in the now." The simple Subject-Verb-Object syntax is clear and direct. If you are speaking in a future tense, you find it easy to make predictions about the future. If you are speaking in the present tense, you find it easier to pay attention to what is happening now. This supports the essence of Scrum: empiricism, or "learning by observation."

SVO-p maximizes focus on the present, at the expense of the past and future. Scrum methods identify, acknowledge, and directly confront the reality of complex software development. The use of SVO-p in Scrum, therefore, might not be optional. SVO-p is the best syntax available for communicating very directly in English. I wonder if one of the foul "Scrum Smells" is the avoidance of SVO-p syntax when communicating about current Scrum projects.

It is my belief that if you are really a candidate for a role in an authentic Scrum project, then you are ready for implementing your communications in SVO-p. Give it a try. If it feels uncomfortable, the discomfort may be about the difficulty of making fuzzy, indirect statements in SVO-p. You cannot easily make such statements in the SVO-p syntax. SVO-p identifies the subject, makes the action clear, and assigns responsibility for the action in the present moment. The directness of SVO-p is the greatest strength of the form. SVO-p supports the Scrum value of Openness by strongly encouraging clarity in each and every sentence.

Scrum and SVO-p confront reality, identify the subject, and assign responsibility. Scrum depends on interactive feedback in the present, and SVO-p supports that interactive feedback by focusing attention on the present moment.

I welcome your feedback about the use of SVO-p in actual Scrum practice. I am eager to learn about your experiences implementing SVO-p in Scrum. Please give it a try, and be sure to email me your feedback on SVO-p.

Those devilish actuals

By Henri Stegehuis

About a year ago, I had been struggling with an important "don’t" of Agile Scrum, actual hours. In the first phase of Sprint planning we take all of our actual hours based activities and transform them to ideal hours. The focus factor or productivity factor transforms the hours for these activities to the desired ideal hours. After this initial process actual hours are expelled from current Sprint.

It may take up to a couple of Sprints to get the team really used to the ideal hours way of thinking. Once they understand and have experienced that removing slack from the estimated hours is compensated by using the productivity factor and that the team has control over this productivity factor, this Agile Scrum concept is in place. During the first few weeks as a ScrumMaster you will find yourself pleased with how planning and estimating are addressed in Scrum.

Then reality is catching on

My company’s biggest assets are we, the employees. We offer software solutions; we offer knowledge and broad experience. It all comes down to selling hours and accounting for them. With fixed price projects this problem is easy to overcome by assigning invoice schemes to Sprint deliveries. However, with non-fixed price projects, the accounting is mostly hourly based.

Potentially, the accounting problem with our contractors could be solved by defining certain effort milestones. There is a third party that is really a tough nut to crack, and we need them instead of them needing us, the government. A lot of innovative projects are subject to subsidies. Every claim for a subsidy has to be accounted for based on actually spent hours. The Burndown chart gives no information, as it is intended to, about actual hours spent on a task. For Agile Scrum the past is not interesting but the future is, can we make it in time? Accountancy for contractors or subsidies though lies in the past.

How to integrate

This has kept me busy for a while. I need actual hours, but I don’t want to track them; it is just for accounting. Also, the team must never get the feeling of being micromanaged. Equally important, upper management may not see these hours; I just spent weeks getting them familiarized with ideal hours and the Burndown chart. I don’t want to give them a reason to return to using old methodologies.

The first approach we tried was having the team write down the actual hours once a week on a separate list. This was not working for two reasons. One, the relation with the real tasks became loosely coupled. If I ever had to explain myself on an audit I wouldn’t be able to do so. Two, there were two lists and the team members became irritated. They demanded a solution on the Scrum Board.

Because we would like to maintain a one-to-one relation between Scrum Tasks and actual tasks, we decided to use the Tasks cards. We used the back of the sticky notes to write down actuals information. At the end of the Sprint, I would take down the Scrum Board, and fill the role of Project Manager by administrating the actuals. The consistency was in place and the administrative actions for recording were relatively easy and outside scope of the team and upper management. The recording at the end of a Sprint, when the result was already in place, was so late that the actuals gave no up-to-date, controllable information.

Unfortunately this solution was not working for the team at all, again for two reasons. One, mixing ideal and actual hours in during the Daily Scrum was making people schizophrenic. Two, the other reason might seem over-sensitive, but turning over the sticky-notes was an annoyance, especially while we already had to tape down the sticky notes because they do not seem to really stick (we would always find a couple of them on the floor the next day).

The last approach though had given us valuable input. While we had to tape down the task cards any way, we didn’t have to use the sticky notes. We have decided to make task cards with a default layout. We still use different colors for non-default tasks. Three-fourths of the new task cards is reserved for the Sprint data and one-fourth with a background pattern is reserved for actual recording. In the morning Daily Scrum, we discuss ideal hours, and before we go home, we write down actual hours for that day.

Conclusion

In recent Agile Scrum projects the layout of the Task cards has changed mostly because of the team’s personal tastes. The concept has not changed and the team agrees with the current solution. We know actuals and ideals are conflicting, and it is not Agile Scrum. Now, we separate them by having a different background on the Task cards, and speaking ideal hours the entire day and accounting for actual hours at the end of the day.. We feel that we have found the best solution to secure our sources of income and still follow the Agile Scrum methodology.

9 Tips for Creating a Good Sprint Backlog

By Luciano Félix

The sprint backlog is a simple list of the tasks that must executed by the team in order to deliver an increment of functional software at the end of that sprint. Sprint backlog creation happens in the second part of the sprint planning meeting with the participation of every team member. Giving some real attention to this process is fundamental to a better understanding by the team about what should be done and to better planning during the sprint. Despite this, many teams still struggle with this activity. I hope these tips will help.

1. Involve every team member in the process. It can’t be said enough: the involvement of every team member in the process of sprint backlog discovery is essential. On a multi-disciplinary team, everyone can contribute to task creation, enabling the team to draw from several different perspectives about the story. This generates a much richer Sprint Backlog than if only coders or a technical guru were involved.
2. Discuss how every item should be implemented. Before any tasks are written on post-its it's necessary for the team to spend some time discussing every story that will be brought into the sprint. In fact, the majority of the meeting should be dedicated to understanding how the team is going to tackle the stories. This discussion will involve creating basic designs, checking existing code, discussing architectural possibilities, and so on. Having a shared understanding about the story and the possible solutions will enable the team to create a task list that truly expresses the work to be done.
3. Have a definition of done. Having a common definition of done in place, available and visible to everyone is extremely important. This definition will serve as a guide to what should be done and will remind the team what the general acceptance criteria are for every item in the backlog.
4. Identify all kinds of tasks. Too many teams focus on coding tasks. The truth is, though, that coding is not enough to deliver real working software. The sprint backlog should include every kind of task: object modeling, coding, learning a new technology, database activities, tests, and so on. Having a posted definition of done will help to remind teams of the tasks they are forgetting. By listing every aspect of delivering working software and going through those tasks, the team will gain a new understanding of the real effort the next sprint will require.
5. Don't estimate tasks at all. This is a sensitive one. Estimating tasks in hours is popular and may be necessary when a team if first starting out. In the end, though, we can drop this without losing much. (See Alan Atlas’ article about this topic) The team commitment to the sprint should be done with the backlog items in mind, not the tasks. After all, if we estimate that a task will take 4 hours but it actually takes 12 hours, as long as the team achieves the sprint goal, what difference does it make? Identifying as many tasks as possible and creating a sense of constant progress during the sprint should be enough.
6. Don't assign tasks up front. Resist the temptation to direct work; the team should decide who is going to do what according to the circumstances. If you start to assign tasks to the “most suitable” team member, it will prevent the rest of the team from learning new things, block communication, and decrease collaboration. Empower and trust the team to manage themselves.
7. Review the sprint commitment. After task identification, when the team has a much better understanding about the real effort that is needed, the sprint commitment should be reanalyzed. Does the selected sprint backlog really fit in the sprint? If not, there are some alternatives. Drop the item with the lowest priority or split stories into smaller pieces. What matters in the end is that the team can commit to something they have a good understanding about.
8. Don't use too much time. Respect the time box. Define a meeting duration and stick to it. Timeboxing forces the team to concentrate and intensively discuss the items, making it much more likely that the tasks will be uncovered. The team cannot always identify everything that should be done during the sprint, but that's not a problem. It is much more important for them to gain a thorough understanding of the stories they are bringing into the sprint.
9. Evolve the Sprint Backlog during the sprint. The team will understand more about the stories as they work on them. New ideas may arise and old ideas may be dropped. The Sprint Backlog should reflect these changes. The Daily Scrum is an excellent time to create new tasks and lose unnecessary ones.

If the team invests the time and effort to build a good sprint backlog it will be rewarded with a much better overall understanding of the work to be done, a sense of progress on a daily basis, and a clear commitment to what will be delivered. It may not be easy, but it will be worth all the hard work.

Explaining the Sprint Budget Chart

The Sprint Budget Chart maps how a team consumes its budget over the length of the sprint relative to the planned budget consumption calculated by ScrumEdge. This chart is based on three variables, the Planned Budget, Budget Used and Actual Completed.

Planned Budget

Once sprint planning is complete and tasks have been assigned to Team Members, ScrumEdge calculates the Planned Budget by assigning a percentage value to each day of the sprint.

Planned Budget:

Planned Budget = Previous Day’s Planned Budget + (100 / Total Days in Sprint)

Example: If a team is working on a 10 day sprint their Planned Budget value will be calculated as follows:

Day 1: 0% + (100 / 10) = 10%

Day 2: 10% + (100 / 10) = 20%

Day 3: 20% + (100 / 10) = 30%

…

Day 10: 90% + (100 / 10) = 100%

Budget Used

The Budget Used line shows what percentage of the the planned budget a team member has used. It is calculated every day by dividing the total number of hours burnt till that day by the total number of hours estimated in the sprint.

Budget Used (Whole Team):

Budget Used = (Total Team Hours Burnt till this Day/ Total Team Hours Estimated in Sprint) * 100

Budget Used (Team Member):

Budget Used = (Total Member Hours Burnt till this Day / Total Member Hours Estimated in Sprint) * 100

Example: If a 2 team plans a sprint where their total task estimates are 100 and burns a total of 12 hours on the first day, and 15 hours on the second day their Budget Used for the first two days will be as follows:

Day 1: (12 / 100) * 100 = 12%

Day 2: (27 / 100) * 100 = 27%

Actual Completed

The Actual Completed line shows the percentage of actual work that is completed in the sprint and is calculated only when a task is completed. The Actual Completed is calculated by dividing the total estimates for completed tasks by the total number of hours that are estimated in the sprint.

Actual Completed (Whole Team):

Actual Completed = (Total Task Estimates for Completed Tasks/ Total Hours Estimated in Sprint) * 100

Actual Completed (Team Member):

Actual Completed = (Total Task Estimates for Completed Tasks for Member/ Total Member Hours Estimated in Sprint) * 100

Example: A team plans a 100 hour, 10 day sprint. 1 task with estimates equaling 7 hours is completed on Day 2 and another with estimates equaling 3 hours on Day 3. On Day 4 a task with estimates equaling 12 hours is complete. The Actual Burn for this sprint would be calculated as follows:

Day 1: (0 / 100) * 100 = 0%

Day 2: (7 / 100) * 100 = 7%

Day 3: (10 / 100) * 100 = 10%

Day 4: (22 / 100) * 100 = 22%

Analyzing the Budget Chart

If used properly the Budget Chart can be a powerful tool. During the course of a sprint, the ScrumMaster can use the Budget Chart to see how much of the plan budget their team uses every day and how much actual work is completed based against the team’s budget consumption.

If the Budget Used line goes over the Planned Budget line, the ScrumMaster should immediately recognize that the team is taking longer to complete tasks than they had estimated. However, this does not mean that the sprint is headed for disaster. It is normal for team members to go over their estimates from time to time. A good ScrumMaster should investigate further to see if this could actually a problem later on in the sprint.

The Actual Completed line is an important indicator of how much work is actually being completed through the sprint. There may be a case that the Budget Used and Planned Budget lines match up perfectly but the Actual Completed line hovers at 0%. This would indicate that the team is using up the time they had planned to spend on tasks, but not actually completing any tasks. It is normal for the Actual Completed line to hover close 0% at the start of the sprint and pick up as the sprint moves forward and tasks are completed.

It is important for ScrumMasters to understand these trends and facilitate the team members in completing committed tasks.

Explaining Sprint Burn Rate Charts

 
The Sprint Burn Rate chart maps the average number of hours a Scrum team burns over the length of the sprint relative to the required burn rate calculated by ScrumEdge. This chart is based on two variables, The Ideal Burn and the Team’s Burn.

Ideal Burn

Once sprint planning is complete and tasks have been assigned to Team Members, ScrumEdge calculates the Sprint’s Ideal Burn rate by adding up the total number of hours required to complete all tasks in the sprint and dividing these over the length of the sprint to get the average number of hours the team should be burning each day to complete their tasks.

Ideal Burn: (Whole Team)

Ideal Burn Rate = (Total Sprint Hours / Number of Days in Sprint) / Total Team Members

Ideal Burn: (Single Team Member)

Total Sprint Hours Assigned to Team Member / Number of Days in Sprint

Example: If a 2 man team plans a 10 day sprint and their total tasks estimates are 100 hours their Ideal Burn Rate would be as follows:

(100 / 10) / 2 = 5

The ideal burn rate stays constant through the course of the sprint.

Team’s Burn

The Team’s Burn is the average number of hours the team burns every day.

Team’s Burn: (Whole Team)

Team’s Burn = (Total Hours Burnt By Team / Number of Days) / Number of Team Members

Team’s Burn: (Single Team Member)

Team’s Burn = Total Hours Burnt By Team Member / Number of Days

Example: If a 2 member team was to burn 10 hours on Day 1, 15 hours on Day 2 and 20 hours on Day 3, their Burn Rates would be as follows:

Day 1: (10 / 1) / 2 = 5

Day 2: (25 / 2) / 2 = 6.25

Day 3: (45 / 3) / 2 = 7.5

The Team’s Burn Rate changes from day to day.

Ideal Burn vs. Team Burn

The Team’s Burn when mapped against the Ideal Burn should give the ScrumMaster an idea of how many hours their team is burning every day. The Ideal Burn tells the ScrumMaster how many hours the team committed to burn every day through to course of the sprint. On the other hand the Team’s Burn tells the ScrumMaster how many hours their team is burning every day.

It’s important to keep in mind that the Sprint Burn Rate Chart does not help predict the success of a sprint. A Scrum team may be working at ideal burn levels and still not complete tasks because of incorrect estimation. However, this chart does give the ScrumMaster an idea of  how much time each team member is spending working on a sprint everyday. If a member’s burn rate is well below the Ideal Burn this chart should help the ScrumMaster raise a red flag and investigate the matter.

Similarly if the Ideal Burn at the start of the sprint is higher than the team’s overall velocity, the ScrumMaster should note that the team may have overcommitted. At this point it would be a good idea to regroup with the team and if need be, revise their sprint plan.

A Cure for Task Estimation Obsession

By Alan Atlas

I often see teams obsess over sprint planning, especially the task estimates. I mean really obsess. Two days of planning for a two-week sprint? Believe it or not, it happens. Even as they complain about spending too much time in scrum meetings, they will insist on arm-wrestling over each and every task estimate. For teams that want to take advantage of their scrum experience and streamline their planning, eliminating task estimates can be an option.

Don’t look so shocked. It is possible. One big caveat, though. For those teams that are new to Scrum, I do not recommend eliminating task estimates until you have established a stable velocity.

Once you have a stable velocity, however, you can use the concepts of story points and velocity to eliminate the need for task estimates in sprint planning. The time you used to spend estimating tasks can then be used more wisely to create working software. I will present a series of steps you can take to gradually eliminate task estimation from your sprint planning process.

Background

Before we get started, let’s quickly recall the reasons why we do the sprint planning things that we do. (We’ll want to make sure we can still meet those needs when we’re done streamlining the process.) We plan the sprint in order to create the following:

1. A shared understanding across the team of the goals of the sprint;
2. A shared understanding of the work that needs to be done during the sprint;
3. An environment in which team members know what to do next (or can find out in seconds);
4. An achievable team commitment to deliver a certain amount of value, expressed as product backlog items; and,
5. A burndown chart that we can use to track our progress through the sprint.

Task estimates most often contribute to goal five above, and for some teams, to goal four. If we can achieve those two items without creating task estimates, then we are free to choose not to use task estimates at all, aren’t we? If you agree, here’s a way to transition away from doing task estimates as part of your sprint planning.

Step 1. Establish Stable Velocity

Use your normal sprint planning process, whether it takes two days or two hours, for each sprint until you can demonstrate stable velocity. (There are many discussions of how to achieve stable velocity out there; it is too large a subject to treat here. For more on agile estimation, I recommend Mike Cohn’s Agile Estimating and Planning.) Make sure your team passes the Nokia test by producing potentially shippable software each sprint (in other words, you’ve proven that you can calculate your velocity correctly). When you have achieved stable velocity, your team will be able to make, and meet, sprint commitments based solely on demonstrated velocity and story point estimates of Product Backlog items. You want to do this anyway as part of having a good scrum implementation, right?

Step 2: Experiment with a Task-Based Burndown

When you think you’re ready to stop estimating tasks, start to use two burndown charts instead of one. Continue to use your normal work-based burndown, which is based on the task estimates from the sprint backlog. Add to it a new burndown chart, which will be based only on the number of tasks in the sprint backlog, regardless of their estimates. The new burndown chart can be called a task-based burndown chart.

Your familiar work-based burndown chart starts with the total of all task estimates for the sprint and, as estimates are updated daily, the burndown continues to reflect the estimated amount of work left in the sprint.  Hopefully it will usually trend down toward zero. Your new, task-based, burndown chart starts instead with the total number of tasks listed for the sprint. Estimates aren’t updated for this chart, and work is burned down when a task is completed (its value on the burndown goes from 1 to 0).  For best results, make sure your task breakdown results in the smallest tasks possible. The task-based burndown chart reflects the estimated total number of tasks left to do in the sprint and not the estimated work effort left. This works best if you have lots of small tasks, typically ones that can be done in a day or less.

Make sure that both burndowns agree and that both give you the same visibility into your progress during the sprint. If you find that the task-based burndown isn’t useful, take a look at Step 3.

Step 3: Shrink Tasks to Improve the Task-Based Burndown

A good, informative task-based burndown chart depends on there being many small tasks to burn down. Conceptually, if you only had one task per PBI on a sprint backlog, you could have a perfectly good work-based burndown chart because the daily updates of the task estimates are given with arbitrary granularity (Now, if your PBIs really have only one task each, it’s indicative that there is a problem with either your stories or your task decomposition). In contrast, the task-based burndown chart for this sprint would be very insensitive on a daily basis, because the tasks would tend to span many days, and progress would not show until a task was completed. The remedy is to make tasks small. A good rule of thumb is that a task should be something that can be completed in a day or less.

Step 4: Stop Doing Task Estimates

When your two burndown charts convey similar information and when you can deliver on velocity-based sprint commitments, you can stop doing task estimates and do away with the work-based burndown. For some teams this will be easy to achieve and for others it could take many sprints. The key to this is to use the idea of velocity correctly. Note that you will still want to be doing the task breakdowns for now. Eliminating them is a different step altogether.

What did we lose when we did away with the task estimates? Task estimates support planning needs four and five from the list above. We still have a burndown chart that we can use to track progress, so we still support goal five.  We have removed the need to support goal four because our team has demonstrated the ability to make commitments based on story point estimates of PBIs and does not need task estimates for validation.

The only thing we might have lost is tangential support for planning need number two. That is, by not asking for estimates, we may have removed some of the mental pressure and motivation to think deeply, look for issues, recall similar efforts, and in general actively bring knowledge and experience to bear on the problem of correctly planning out the tasks. How big a deal is that? The answer to that question is unique to you and your team.

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

Scrum Delivers

By Boris Gloger

“In factories around the globe, Toyota consistently raises the bar for manufacturing, product development, and process excellence,” says Jeffrey K. Liker in The Toyota Way. He goes on to define fourteen principles that he claims drive Toyota’s success.

If we accept his premise that Toyota is the world’s best manufacturer and that this success is based on fourteen clearly identified principles, then we should model these principles in our own product development processes to increase our own success. Scrum practices map very well to these principles and provide an effective way of making them part of your day-to-day workflow.

Principle 1: Base your management decisions on a long-term philosophy even at the expense of short-term financial goals.

In a Scrum project, the vision is defined by a key representative of the organization: the product owner. He translates the company’s long-term philosophy (road maps or financial goals) into specific, tactical decisions within the project. These decisions are communicated to the project through the product backlog.

Continue reading this article