Some of our teams have struggled with not being able to complete the testing hours for stories in a sprint, and thus not reaching DONE for the story. One team has vollied up the idea of doing the development work in one sprint & sizing that then doing the testing in the next and sizing that. This doesn't seem like the best solution, but wanted input on others experiences. We also think the root cause could be that the stories are too big for the 3-week sprint duration. At this time we are not using any automated testing methods, but are working to begin this later this year. Please provide input & experiences. Thank you!
1. Agile Teams need to have the capability to size their stories and the story is not DONE unless it is tested. So, teams should have the ability to estimate for both development and testing. It seems that this is not being done in the case mentioned above.
2. Testing in the Agile World is different. Automation is key. We dont have the luxury of elaborate test strategies, plans or execution in manual fashion.
Without a bit more input it's hard to get very specific on identifying the source of the problem here but I'll see what I can do to point you in the right direction.
The first thing I'd say is that either the team is biting off more than it can chew (stories are too big) or there may be an immature (not derogatory - just earlier development level) development approach that looks at testing as something that happens after development.
If you take some of the test driven development (or even test driven design) approaches one of the first questions a developer needs to ask and answer is "how will I test this?", which isn't wildly different than the "how do I know I am done?" question that should always be front of mind, regardless of the flavour of development style.
As far as how you deal with leftovers I suppose you leave that story in the backlog as it isn't done and release it at the end of the next sprint.
I think you'll want to add some team reflection to your process - your devs will know what the main problems are and should bring them to the foreground...
Hope that helps!
cheers,
Darrell
Without a bit more input it's hard to get very specific on identifying the source of the problem here but I'll see what I can do to point you in the right direction.
The first thing I'd say is that either the team is biting off more than it can chew (stories are too big) or there may be an immature (not derogatory - just earlier development level) development approach that looks at testing as something that happens after development.
If you take some of the test driven development (or even test driven design) approaches one of the first questions a developer needs to ask and answer is "how will I test this?", which isn't wildly different than the "how do I know I am done?" question that should always be front of mind, regardless of the flavour of development style.
As far as how you deal with leftovers I suppose you leave that story in the backlog as it isn't done and release it at the end of the next sprint.
I think you'll want to add some team reflection to your process - your devs will know what the main problems are and should bring them to the foreground...
Hope that helps!
cheers,
Darrell
1. Agile Teams need to have the capability to size their stories and the story is not DONE unless it is tested. So, teams should have the ability to estimate for both development and testing. It seems that this is not being done in the case mentioned above.
2. Testing in the Agile World is different. Automation is key. We dont have the luxury of elaborate test strategies, plans or execution in manual fashion.