Agile ways to Done - some tips

Knowing when you are finished is not only a problem in development, but also in art. Leonardo DaVinci once said that a work of art is never finished, but at some point simply abandoned. So he was convinced that every work of art can always be improved. With modern technology it often behaves similarly. For example, if you have the task to create a web design for a company, you can do it within one day, or you can spend many weeks on it. There is always something to improve, add or embellish. Or you should create a robot to replace the waiters in a restaurant. You could just stop where the robot rolls to the table and puts the food down. But you could have much higher goals, for example to make the robot walk on human-like legs, make it smile or program it to make smalllatk. That's exactly it: you have to define a goal to recognize when you have reached it.

The makers and users of Scrum recognized this quite early. Therefore the definition of the Done in Scrum is a common standard that all users recognize and use. In Scrum the Done is not only the goal but the actual meaning of the whole Scrum concept. Basically, in Scrum everything is done so that the Done can be achieved. Every single sprint exists only to achieve the Done. If you don't think you will reach your goal in this sprint then don't start it at all but break it down into smaller units so that each individual sprint can actually reach its Done in the given time.

Anyone who has ever tried to combine user experience and Scrum knows that conflicts arise. They are mostly tactical problems, because both UX and Scrum have the high goal of creating outstanding products with added value for the user. But often the two methods cannot be reconciled. The definition of Done is very controversial. In Scrum, Done is defined in such a way that the software works. Most conventional UX methods, on the other hand, only want to talk about Done when a software has been designed, tested, tried and revised so that it is well received by the users. In Lean UX, there is another aspect that comes into play: the benefit for the user. Here, done is only considered achieved when the product is accepted or approved by the user or customer. So there are very different views on when the work is finished. And these could hardly be more different.

With Scrum the software must work. With Lean UX the customer has to be satisfied with it. That is something completely different. Even in the planning process this can lead to lively discussions. Someone who adheres to the UX method will devote significantly more time to completing a task than someone who is dedicated to the Scrum approach. Sure, because developing, testing, checking, revising takes much more time than just developing a working product. In an agile team this can lead to a lot of frustration.

Josh Seiden worked on getting a grip on this discrepancy and defusing the problem. Together with two Scrum trainers he found ways to solve it. In his article he presents some approaches. A good approach is to define a new task every day. No story should take longer than one working day. Larger tasks have to be broken up to fit into one day. Ideally, each of these stories should aim for a visible change to the product so that the team and the customer can see the progress. According to Seiden, trust and transparency can be greatly increased with these rules.
The second approach is to abandon the traditional definition of finished design. No design is ever finished. Here Josh Seiden agrees with DaVincis statement. This is all the more true in a world where circumstances are constantly changing. Moreover, every product also changes the user's environment. A development that is never completely finished is therefore generally in every product itself. Of course, you have to understand that a pre-release is not the same as a fully accepted product.
Finally, Seiden points out that it is extremely important to distinguish between "done" and "approved". Done is so important for all scrummers because it determines their daily work. However, Done is not always "done". A done one can consist of 27 different dones. Or more. Done is important. Every single task must be tackled and completed. But a final finished product often cannot be equated with a single Done.