Last week I had a discussion in which I was told that in SCRUM, it is common to work on requirement analysis, development of code based on that analysis, and testing of the code all within the same 4 week iteration. (They happen to run 4 week iterations here) Has anyone seen BA, Dev and QA in the same iteration before? My experience is that the BA documents requirements in Iteration 1, the developers then code of the requirements in Iteration 2, the QA tests that code in Iteration 3.
I am working at a new employer who is at the beginning of a project and just setting up their structure. So there is not a lot of past history to look back on.
Thank you!
A key principle of Scrum is its recognition that during a project the customers can change their minds about what they want and need.So it is an iterative process.
SO As soon as the requiremetn analyst is able to get the first set of requiremetns ot, the desig team starts working.As soon as the design team is able to get the basic design out, the development starts and so forth with testing and implementation phase. So , it is not necessary for the teams to have the 1 week iteration process. They all will work together and design can even start during the 1st week itself...
Now in SCRUM, THERE ARE 3 MAIN ROLES
Thanks
Supriya
analystschool.com
free demo session today at 8.30 p.m CST .Email me if you are interested to attend the free session email : [email protected], [email protected]
free demo session today at 8.30 p.m CST .Email me if you are interested to attend the free session email :
[email protected], [email protected]
Here are a couple of differences with what you wrote.
At the end of a sprint you need to have working software. I would even go so far as to say nearly production ready. So 1 sprint for docs, one for dev one for testing doesnt fit the model.
During a sprint the backlog doesnt change. If they need to work on something else in the backlog other than what was decided, the sprint is canceled and is automatically red.
My preference is for 2 week sprints with requirements always staying ahead of the sprints. The sprints end up being 1 week of development and then 1 week of the developers and testers fixing the code so it really works well. Requirements can be somewhat clarified during the sprint but generally are complete before the sprint is done.
We have a lot of posts on agile requirements at http://requirements.seilevel.com/blog/category/agile-requirements
Hi John,
Yes, I have been in Scrum teams where all activities take place within the same iteration. What you decided sounds a lot like a 'scrumfall' variant where there are still elements of waterfall that fall outside of Agile/Scrum principles (in this case, the demarkation of BA/QA/Dev roles and explicit handoffs between iterations being the red flags). This isn't necessarily a bad practice (I always advocate finding what works best for your team), but it is one that I would review and see if there is a more effective way so that everyone is collaborating together more closely.
In order for a sprint to start you need to have sufficient requirements/user stories that can be estimated upon, both from a story point and task levels. This means that everyone on the team needs to have a 'good enough' understanding of what is entailed by the description of the user story, and that the conditions of acceptance of a user story are clearly understood and decided upon. However not every little requirement detailed needs to be defined and documented prior to accepting a user story for a sprint. For example, it doesn't meant that you need to have all 30 business rules that will be implemented already defined, but it does mean you need to know that you have about 30 business rules to implement for the story. As a result the 'BA' work that needs to be done for a given user story straddles multiple sprints - the definition of the user story and its acceptance criteria happens in the previous sprint while any particular details that require elaboration is performed during the sprint.
In terms of dev vs. QA work, your team needs to come up with a definition of done for a given user story. This definition describes what elements have to be in place before you can close off a user story. I typically advocate making this definition include as much as possible - otherwise you end up having multiple user stories for completing one piece of user functionality, which means that completed user stories are not actually helpful in producing 'working product' for the end of a sprint. I like to have my definition of done include all unit testing, system testing, system documentation and user documentation (manuals, training materials, etc.). While this may seem like a lot it helps your team focus on getting smaller pieces of functionality done completely within a shorter timeframe, rather than having lots of partially completed items done at the end of a sprint. If you can't complete all these tasks within one sprint for most of your user stories it's an indication that your stories are too big or your team doesn't have all the right pieces on board.
At my organization on my current project, a 4-week sprint is 1 week of requirements analysis and design, 2 weeks of development and 1 week of testing. Generally speaking, that is. If something is "done" and ready to test in week 3, then QA will test as soon as it is ready. Developers tend to start coding framework on day 1. But to answer your question, yes it is all done in one sprint.
brought to you by enabling practitioners & organizations to achieve their goals using: