The product owner and the team lead had a lively conversation over lunch; much was discussed about the development in/progress of a very cool feature during the present sprint, and both agreed that certain changes had to be made to the original definition and implementation / nothing too drastic, but certainly something noticeable. The team lead took a snapshot of the scribblings on a napkin for reference.
After lunch, the team lead went right to work. Code was re/factored and checked/in and the status of the story was updated to Done,
waiting for the product owner to review once again and mark it as accepted. Or so the team lead thought.
As the test engineer reviewed the new code in the latest build, he was befuddled // the new feature was somewhat different from what he originally discussed with the team lead and the story description. Why did it change? When did it change? And where are the changes documented? He asked the team lead these questions, and the ensuing discussion on why and when the changes were decided made the test engineer feel just a little bit left out...
, the type of changes and decisions that the product owner and the team lead made can be documented via Conversations
. By using this feature, the type of quick feedback // whether decisions, changes or additional information // that might have bearing on the development of a feature can be readily captured as part of a Story (or any other asset). Someone looking at the detail of such a story (say, the test engineer) would have the information readily available, which describes the twists and turns that took place in developing such. He might not have been privy to the actual discussion, but the Conversations captured would certainly be helpful in understanding why the story changed
and who requested the changes
as an organic change log, and keep everyone in the loop!