Skip to main content

two agile antipatterns

Both of these have been crossing my path with increasing frequency in recent months (not at work, but in conversations with others whom one would think would know better):

1) Stories are scheduled work for features. Stories should not include:
  • testing
  • refactoring
  • documentation
  • undefined customer support
  • calling your mom
The problem with writing stories for stuff other than scheduled work on features is that you completely undermine the concept of velocity.

Velocity is the number of story points accomplished per iteration. If you assign story points to activities other than scheduled work on features, you cheat the business of accurate information about release schedules. (Although it might make you feel better to be accomplishing so many points each iteration, if you are not delivering features, you fail.)

2) Doing it "by the book".

Part of the agile culture is to have retrospectives at the end of each iteration. Each retrospective is an opportunity to change your process.

So if you're doing 2-week iterations, at the end of a year, you've had 25 or so opportunities to change your process. At the end of two years, 50 process changes.

If after all of these retrospectives, you are doing your work the same way you were at the beginning, you fail.


caike said…
While I completely agree with your #2, I'm afraid I disagree with #1.

Testing and refactoring should be taken into consideration in the teams' definition of done.

If you are doing TDD, besides modeling you are also testing. Even if you are not doing TDD, I don't think you should consider a story complete if it is not tested and refactored. A story should be considered complete when it delivers business value to your customer AND at the same time follows good agile and software craftsmanship principles.
paddyslacker said…
Caike, I don't think that's what Chris is saying. Whilst the actual tasks performed to deliver a story should and will include testing and refactoring, they should not be stories in and of themselves, nor should any story points be assigned to them.

For example, you might need to regression test or refactor a legacy application (I'm using Michael Feathers' definition of "legacy" here - i.e there are no automated unit tests) as part of an iteration. These are not stories as they do not deliver new features to the business.

Instead, this work is more like technical debt, and as the code base became cleaner and test coverage increased over time, the team would see an increase in the number of story points delivered over time.
caike said…
Oh, I see!
My apologies for my misunderstanding.
"(...) they should not be stories in and of themselves" - this makes it clear. Great post.
TestWithUs said…
This comment has been removed by a blog administrator.

Popular posts from this blog

Reviewing "Context Driven Approach to Automation in Testing"

I recently had occasion to read the "Context Driven Approach to Automation in Testing". As a professional software tester with extensive experience in test automation at the user interface (both UI and API) for the last decade or more for organizations such as Thoughtworks, Wikipedia, Salesforce, and others, I found it a nostalgic mixture of FUD (Fear, Uncertainty, Doubt), propaganda, ignorance and obfuscation. 

It was weirdly nostalgic for me: take away the obfuscatory modern propaganda terminology and it could be an artifact directly out of the test automation landscape circa 1998 when vendors, in the absence of any competition, foisted broken tools like WinRunner and SilkTest on gullible customers, when Open Source was exotic, when the World Wide Web was novel. Times have changed since 1998, but the CDT approach to test automation has not changed with it. I'd like to point out the deficiencies in this document as a warning to people who might be tempted to take it se…

Watir is What You Use Instead When Local Conditions Make Automated Browser Testing Otherwise Difficult.

I spent last weekend in Toronto talking to Titus Fortner, Jeff "Cheezy" Morgan, Bret Pettichord, and a number of other experts involved with the Watir project. There are a few things you should know:

The primary audience and target user group for Watir is people who use programming languages other than Ruby, and also people who do little or no programming at all. Let's say that again:

The most important audience for Watir is not Ruby programmers 
Let's talk about "local conditions":

it may be that the language in which you work does not support Selenium
I have been involved with Watir since the very beginning, but I started using modern Watir with the Wikimedia Foundation to test Wikipedia software. The main language of Wikipedia is PHP, in which Selenium is not fully supported, and in which automated testing in general is difficult. Watir/Ruby was a great choice to do browser testing.  At the time we started the project, there were no selenium bindings for …

Open letter to the Association for Software Testing

To the Association for Software Testing:

Considering the discussion in the software testing community with regard to my blog post "Test is a Ghetto", I ask the Board of the AST  to release a statement regarding the relationship of the AST with Keith Klain and Per Scholas, particularly in regard to the lawsuit for fraud filed by Doran Jones (PDF download link) .

The AST has a Code of Ethics  and I also ask the AST Board to release a public statement on whether the AST would consider creating an Ethics Committee similar to, or as a part of the recently created Committee on Standards and Professional Practices.

The yearly election for the Board of the AST happens in just a few weeks, and I hope that the candidates for the Board and the voting members of the Association for Software Testing will consider these requests with the gravity they deserve.