I tried this and found its working. I tried to pick a test
story before implementation. Off course this should be discussed with team and
Product Owner. If stories are big and can be divided into test and implementation story,
then we try to do that and I pick the test story one sprint before the actual
implementation. As per one of my friend, we can termed this test story as
analysis story. But I would like to term it as test story.
The benefits I saw:
1.
After I finished with my test design
(Specification by example), I did a review with my development team, and this helped my
team to really consider and think all possible constrains and helped them to understand
the requirement better. Everybody brought different question which needs
business clarification.
Now imagine, this could have been a
disaster if it comes up during implementation.
2. when we asked clarification from business, (we
also had test scenario review with business) they also had to given a rethink
about their requirement. Because of the test scenarios, business is able to see
the impact of the requirement. Business had to redefine their requirement which
is now more polished.
3.
Finally in the sprint I was able to help my development
team and business with my test scenarios, able to bring business and
development team in the same direction.
4.
Sprint after when the actual implementation
happened, it was smooth and we had quality output at the end. Without any
trouble team developed the functionality, we had a good test results.
Well Bidyut...this is what is called as TDD. Test driven development. Ideal Agile implementation should consider TDD along with CI- continuous integration; faster way to market your deliverables.
ReplyDeleteOn the other hand, I like the idea of saying it a "Test story". This is more simpler form of adopting TDD in sprint.
Cool. Keep it up !!
Nice first post Bidyut. I just think that using test stories is one way to go, but I would prefer having stories business focussed. Slicing stories technically or work oriented starts hiding the business focsu.
ReplyDeleteThe way you use it sounds like to split the work into pieces (just for the sake of having something to move on the board). But one should ask - why a story for this? Why not having the business story and start preparing it a sprint or more before. Or start working on the story with different lanes before you start the real implementation - like test definition, requirements clarification,... This way you can see all activities that belong to the story and you can maybe just spot more potential flow topics.
What do you think?
I agree - and personally, I feel that the story is too big if it needs test specification a sprint ahead. With agile product development it might even be that the story does not make it into next sprint, because priorities have changed, or might be altered, so that the effort is wasted.
DeleteBut I like the blog a lot :)