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!
Unless I've misunderstood the principle, agile sprints are about layering on features until you arrive at some final release.
But software can become unwieldy complex and choosing the right data structures and class patterns, for the application, is crucial - isn't it?
So, how can you decide on the right data structures and classes and patterns, at the very beginning of the process, if in the first sprint, you are only dealing with a few of the overall application features?
Do you continually refactor and re-write as new feature-information is presented? Or is there some overall application design architecture happening up-front?
BTW, I'm not a formally-trained computer scientist, or software developer.