1) Stories are scheduled work for features. Stories should not include:
- testing
- refactoring
- documentation
- undefined customer support
- calling your mom
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.
3 comments:
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.
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.
Oh, I see!
My apologies for my misunderstanding.
"(...) they should not be stories in and of themselves" - this makes it clear. Great post.
Post a Comment