Agile Business Change Blog Thoughts on Agile Strategic Business Change and Agile Delivery

Tweet

Mail

We are all happy with the concept of standards, well I hope we are anyway. A standard gives us a baseline to work with and allows us to have a common understanding of what to expect. Coding standards are pretty universal in development. Well I say that, but I am amazed how often they don’t seem to be in place, used, or validated against with static analysis or manual code reviews. But that’s another issue. Few people would contest their value or importance in generating quality code. So let’s assume we are happy with the value of coding standards. They allow a developer to understand what is expected of him or her and the technical lead doesn’t have to repeatedly state things like variable naming conventions and layout standards.

We can use the same principles with stories. We want the acceptance criteria of stories to be concise and relevant. If we add too few criteria, we risk the developer failing to make the code meet required functionality. Clearly a problem. However the reverse is also a problem. If we list everything that the code must do, we risk burying the important stuff in low value detail. That’s a great opportunity to build the wrong thing.

OK, let’s look at an example. Let’s assume we are building a web site. We want the back button to move to the previous screen by default. Do we add this as criteria to every story? Its rather low level and but we will probably test it and we still want the developer to understand that it’s a requirement. Do we want to clutter the story with this level of detail? No we don’t, but we still want the developer to make sure it works or we end up with the cost of a failed test, correct and retest cycle. So what do we do with it? Add it to a list of ‘Development Standards’.

Development standards are default criteria that by default apply to every story. It adds a checklist for developers and testers alike to make sure we have developed and tested to the baseline expected.

So what is the lifecycle of the Development Standards? In general they start off as an empty list. There are a number of trigger points that can add something. A test that gets run and a story failed because ‘I didn’t know you were going to test for that?’ scenario. If its agreed that this is a standard thing that will be checked for such as the back button works, add it to the list. Another trigger is a ‘horizontal story’. i.e. something that adds a feature to past work and should be included in all new stories. Adding the breadcrumbs to a page is a good example. When the story is run, all pages built so far should be updated with the new feature and the breadcrumb criteria added to the Development Standards so it will be included in all pages built from now on.

So the list extends over the period of the project to cover things that have been missed and new standards as they are defined. The stories are not cluttered with low value criteria but we still know they are needed. Now what happens if a Development Standard is not appropriate for a specific story? The simplest example would be for a story where it simply isn’t appropriate such as adding the breadcrumbs example to a story delivering a printed report. Well it’s not that hard to agree it’s not appropriate when the story is brought into play. A more interesting example is when it is logically could be appropriate but in the particular case isn’t. An example here is using the back button to go back to a login page where we don’t want users to be able to navigate back to login details. Well in that case we do add we add to the story an ‘overriding’ acceptance criteria line saying that ‘the back button is disabled’. This should be hard for a developer or tester to miss because it will stand out as something ‘important’ to note as its listed with all the other significant criteria on the story.

Well its worked for me in the past and got past the problem of developers and testers not having a common understanding of the low level detail that we really don’t want to have to talk about all the time when the story specifics are far more significant.