I'm working with a team new to an area I have a lot of domain knowledge in, and this article rings true.
I feel there's a lot of emphasis put on the user story process where I am, that adds little value at the end of the day.
I went on a two week hacking spree during the break and found myself loathing with every fibre of my being the need to explain - because the code I'm writing is effectively self documenting; and I feel you only need a very brief conversation to paint the bigger picture - the why.
Job Stories might not hold the full answer, but they seem to be a step closer.
From the article, a comparison:
It's harder to write a test against the why, but that's not the point - the why influences the design and is disconnected from the testable criteria.
I feel there's a lot of emphasis put on the user story process where I am, that adds little value at the end of the day.
I went on a two week hacking spree during the break and found myself loathing with every fibre of my being the need to explain - because the code I'm writing is effectively self documenting; and I feel you only need a very brief conversation to paint the bigger picture - the why.
Job Stories might not hold the full answer, but they seem to be a step closer.
From the article, a comparison:
User Story:As a moderator, I want to create a new game by entering a name and an optional description, so that I can start inviting estimators.
Job Story:When I’m ready to have estimators bid on my game, I want to create a game in a format estimators can understand, so that the estimators can find my game and know what they are about to bid on.
It's harder to write a test against the why, but that's not the point - the why influences the design and is disconnected from the testable criteria.
No comments:
Post a Comment