Forums for the Business Analyst

 
  Modern Analyst Forums  Business and Sy...  Agile Analysis ...  Activity within a sprint (aka iteration)
Previous Previous
 
Next Next
New Post 8/30/2010 10:14 AM
User is offline John M Hinkel
1 posts
No Ranking


Activity within a sprint (aka iteration) 

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!

 

 
New Post 8/30/2010 12:45 PM
User is offline [email protected]
22 posts
9th Level Poster


Re: Activity within a sprint (aka iteration) 
Modified By training@analystschool.com  on 8/30/2010 2:46:23 PM)

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]

     

 
New Post 8/31/2010 8:14 AM
User is offline Anthony Chen
63 posts
8th Level Poster


Re: Activity within a sprint (aka iteration) 

 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

 

 
New Post 9/1/2010 11:21 AM
User is offline Jarett Hailes
155 posts
6th Level Poster




Re: Activity within a sprint (aka iteration) 

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.

 
New Post 11/22/2011 7:52 AM
User is offline dldelancey
61 posts
8th Level Poster


Re: Activity within a sprint (aka iteration) 

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.

 
Previous Previous
 
Next Next
  Modern Analyst Forums  Business and Sy...  Agile Analysis ...  Activity within a sprint (aka iteration)

Community Blog - Latest Posts

Fabricio Laguna talks Business Analysis and AI
I recently connected with Fabricio Laguna, aka The Brazilian BA. Fabricio is a passionate and pioneering business analyst from Brazil. During our conversation, we had a thought-provoking discussion on how artificial intelligence stands to shape the field of business analysis in the years ahead. While AI promises to transform many aspects of busines...
Business Architecture, Ontology and More with Terry Roach
It's been a privilege meeting Terry Roach, a visionary in the field of enterprise architecture and business architecture. Terry's insights into the evolution of business models, the importance of ontology in architecture, and the potential of AI to shape our future were not only thought-provoking but also a reflection of his extensive exper...
Today I had the pleasure of chatting to Jignesh Jamnadas, Chief Operations Officer at Mosaic, about his Blueprints for Success. As a Senior Finance and Operations Executive, Jigs (as he is known to many) has a holistic understanding of all facets of business and a flair for managing both people and processes. Having worked with Jigs, I was struc...

 



Upcoming Live Webinars




 

Copyright 2006-2024 by Modern Analyst Media LLC