Career Forums

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

1. the “ScrumMaster”, who maintains the processes (typically a project manager)
2. the “Product Owner”, who represents the stakeholders and the business
3. the “Team”, a cross-functional group of people who do the actual analysis, design, implementation, testing, etc.

   
   

   Each day a project status meeting occurs. This is called a “daily scrum”, or “the daily standup”. This meeting has specific guidelines:

   • The meeting starts precisely on time.
   • All are welcome, but only “pigs” may speak
   • The meeting is timeboxed to 15 minutes
   • The meeting should happen at the same location and same time every day

   During the meeting, each team member answers three questions:

   • What have you done since yesterday?
   • What are you planning to do today?
   • Do you have any problems preventing you from accomplishing your goal? (It is the role of the ScrumMaster to facilitate resolution of these impediments. Typically this should occur outside the context of the Daily Scrum so that it may stay under 15 minutes.)

   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]

    

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.