Reading the agile-testing list recently, I came up with a few questions that I have seen a few answers to, but would like to figure out a few more details on.
How do people out there handle "documentation"? "Requirements"? We have user story cards, and we all recognize that these cards don't have the necessary detail. We do try to have the conversations that the user story cards should necessitate as well. The success varies, but still, there are details associated with a card that we still don't do a very good job of documenting.
We have struggled with where to put this info. We are all .NET, running TFS. We have the Cochango Scrum for TFS framework that sits on top of TFS, but we aren't very good about using it. It contains Product backlog items, Sprint backlog items, bugs, imepdiments, etc ..... The team just hasn't been very good about actually putting stuff into it.
2 sprints ago, we tried a wiki page. One guy spent a bunch of time documenting everything he could as the 'power of 3' meetings occurred at the beginning of the sprint. Then, nobody touched them again.
We have remote employees, and they tend to be impacted the most, especially remote testers. They get notification that a user story is code complete, and then they tend to come to me and say "I don't know where to even start with this story" (yes, they should have been involved from the beginning .... baby steps).
So, how are other people handling documenting the info for a user story?
Thursday, July 10, 2008
Questions, and more questions
So, I have been reading Lisa Crispin's blog lately, and as usual, I have read most of her recent ones with a whole bunch of "yeah, but what if ... ?" questions in my head. I thought about just emailing her directly, but eventually decided that other people might have similar questions, and well, honestly, it's been a while since my last post.
I think the biggest thing that I have read from her recently that I have difficulty with is the ides of focusing on one story at a time thing. To quote her: "Try to quit multitasking, and focus on getting one thing done".
Hmmmm .... but what if you can't, because people above you won't let you? What if, at any given time, you are juggling half a dozen tasks? To take that variable out of the equation, what if the stories' interdependencies aren't clear enough, and you really can't finish one story until another story (that has not yet been completed) *gets* completed?
In my team, we have enough people involved who aren't really a part of the team, that we end up with a nontrivial amount of "this story is waiting on X person before it can continue".
Of course, fundamentally, I *know* the answers to many of these questions .... Have a clear product owner, have people who are more dedicated to the team, etc. But what if we can't? Are there still ways to work around those "higher than us" non-commitments, and still succeed as a team?
I think the biggest thing that I have read from her recently that I have difficulty with is the ides of focusing on one story at a time thing. To quote her: "Try to quit multitasking, and focus on getting one thing done".
Hmmmm .... but what if you can't, because people above you won't let you? What if, at any given time, you are juggling half a dozen tasks? To take that variable out of the equation, what if the stories' interdependencies aren't clear enough, and you really can't finish one story until another story (that has not yet been completed) *gets* completed?
In my team, we have enough people involved who aren't really a part of the team, that we end up with a nontrivial amount of "this story is waiting on X person before it can continue".
Of course, fundamentally, I *know* the answers to many of these questions .... Have a clear product owner, have people who are more dedicated to the team, etc. But what if we can't? Are there still ways to work around those "higher than us" non-commitments, and still succeed as a team?
Subscribe to:
Posts (Atom)