Acceptance Criteria and Definition of Done

In order to improve continuously cross-functional teams are encouraged to expand their Definition of Done constantly. It is true that often in large-scale product development competence requirements, test environment costs and many other restrictions could (in practice) make this expansion at least non-optimal. Many companies have started to solve this problem by adding supporting test teams that are actually xFT subordinate teams. I do not mean that all the testing is done by supporting teams, but for example in mobile network development the investment to have a dedicated e2e radio and core network for every team is not feasible. Still the aim must be that these tests are included in the xFT (and subordinating teams) Definition of Done. That makes it possible to expand DoD and embed more and more tests into xFT cadence. When this is supported by regular (1-2 month) Feature Chartering all the teams have same goals, and in optimal case are able to work daily and hourly with the same SW. This removes the need for handovers and when higher level tests are automated there is real context for scaling the development.

For User Stories there is always defined Acceptance Criteria. If xFT only consists up to functional testing then this criteria might not be wide enough. When we have also the supporting teams and their special competence available in Sprint Planning, we are starting to approach customer acceptance as well. Together with DoD this acceptance criteria should be seen as the main requirement for the User Story (and for the whole sprint in this example). This leads us to acceptance Test Driven Development, aTDD. When full organizational competence and whole development chain is available in planning, we are actually removing organizational impediments towards the flow. And tests are defined and implemented in the beginning of sprint, which leads to situation that they become clear requirements for team´s work. This is supported by the fact that teams have clear goals, they share the same context and most importantly everyone in the organization is working with the highest value adding items. These business-facing acceptance tests must be automated in order to have them available for all teams in the coming sprints and therefore expanding DoD.

Definition of Done and Acceptance Criteria are also possible to implement on feature and release level according to same principles. This gives whole enterprise same process and language and therefore further removes impediments and automatically makes enterprise more Agile. This kind of thinking is often against what has been done previously; long check lists and documented handovers that very often lead to slow development. We believe that it will take years for very large Companies to get into this level, but the rewards are worth trying.

Conclusion is that Agile gives also enterprises the guidance how to scale and how to make whole organization work according to same goals. In order to get this working most of the low-level impediments need to be removed first and when expanding DoD also higher level (organizational) impediment removal follows. Things become visible and organization needs to act in order to improve. This is what counts and will make the difference towards true Agile Enterprise.

Advertisements

About Henri Kivioja

I believe in teams, personal development, humanity and good life.
This entry was posted in Agile Thinking, AgileTesting, All and tagged , , , . Bookmark the permalink.

5 Responses to Acceptance Criteria and Definition of Done

  1. Maybe it is worth to consider that extending DoD or Acceptance Criteria makes the User Story bigger. In a large complex system like a mobile network creating story for a 2 weeks sprint is hard even without acceptance testing requirements. So extending the scope of the story can easily lead to technical splitting of the story which means the team won’t create business value in some sprint.
    Also I don’t see how introducing subordinate test team can lead to a situation when the amount of handover is decreased. On the contrary adding more layer to the development creates more handover situation.
    We need to balance between fast feedback (= acceptance testing in the DoD) and overhead of the handover, communication and synchronization between different parties in the organization.

  2. Henri Kivioja says:

    Hi Balazs, I think it goes like this: the work is anyway needed in the organization and product/feature. I believe that we need to enable that work is done in the correct context and with optimal organizational setup at hand. It is about creating value networks (as Jurgen Appelo uses them). From individual xFT perspective things might look as you say here. If there is handover inside teams or between teams we should align the organization that self organization happens around the work. As Bas Vodde and Craig Larman are saying: watch the baton not the runners 🙂 I would be happy to share some deeper thoughts on this next week. Great comments, thank you!

  3. Vasco Duarte says:

    You make a good case for separate xFT teams based on the assumption that the feature/functionality you are testing cannot be tested without that extra work (separate, expensive test environment).
    This is not the case for most (perhaps 99%?) of the work that we do. The only thing that requires a live network is the actual radio signal testing, correct?
    Why not create an environment that is *cheap* and every team can use? Why not create a mock of the radio network that simulates the “network” part of it but not the “radio” part of it?

    A long time ago I had a very similar discussion with some hard-core firewall programmers. “We cannot test on the virtual machine” was their statement. However, once they broke that “mental barrier” they were able to considerably speed up and automate their test cycle. Heavily reducing the Work In Progress due to separate testing environment needs.

    I would actually challenge you to change your environment, instead of accepting the current assumptions as immutable. YOu may not be able to do it in the end, but what you will learn will make you much better. And that alone is worth the effort! 🙂

    • Henri Kivioja says:

      I know that in the end we need to have true e2e covered. History has shown that radio and core need to be tested together at some point, it is mainly due the complexity in the domains. This does not rule out the fact that it is (and has been) possible to introduce cheaper solutions like mocking/simulating of some parts of the network. I like the attitude you are showing here, challenge everything should be one of our first rules. So actually the combination is what I am after, but at the same time I want to give to teams new tools and viewpoints to actually challenge their process. And that leads to real learning, happening on team and individual level. Many thanks for you comments, Vasco.

      -H

  4. Pingback: User Stories – The Confusion Continues « Tales from a Trading Desk

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s