Forums for the Business Analyst

 
  Modern Analyst Forums  Business and Sy...  Agile Analysis ...  Basic questions
Previous Previous
 
Next Next
New Post 9/17/2018 4:46 AM
User is offline Prasad 01
3 posts
No Ranking


Basic questions 

During sprint planning meeting, we assign developers to each user story and this is what most of the scrum teams do . If this is the norm in scrum, below answer given by me should have been completely correct. But unfortunately, it's only partially correct. Can anyone please give more clarity on this? (Please click on below hyperlink)

https://ibb.co/ifRCBe

 

2nd question:

Please check screenshot here : https://ibb.co/i35djz

10 participants ( few developers, few QA guys, 1 product owner)

the correct answer is marked in green in screenshot.

(a) What I am not getting is how can we divide them in 3 teams?

(b) Also, my answer 2 teams (separate team for Developers and QA) is wrong.  But, if we have mixed team of QA and developers, would that be best approach ?

 

3rd question:

Also, is it true that there is no prescribed structure of daily stand-up? I used to think 3 questions are the format we should follow.

(a) What you did since last standup meeting?

(b) What impediments you faced?

(c) What are you planning to do till next standup meeting?

 
New Post 3/6/2019 12:10 AM
User is offline simonteo
3 posts
No Ranking


Re: Basic questions 
  1. In my world, we generally do not assign task to indiviual / pair during planning. We look at the prioritized product backlog and do estimation for each top stories. And based on the past sprint velocities and commitment from each members, we will decide which stories will go into the Sprint Backlog. 

    During the standup, individual or pair will pick the story that they would like to work on.

    1. Scrum dictate that each tam should be 3-9 team. 

      Below there's an article that study the ideal size for a scrum team to be productive. 

      https://agilepainrelief.com/notesfromatooluser/2016/10/choosing-the-team-size-in-scrum.html#.XH-JTs8zZQI

      For a team size of 3, it should be expected to perform as a Feature Team (where all members are cross-functional and cross-component). QA role can do dev, Developer role can do QA. 

      As such, dividing them into 3 teams (4,3,3) is totally workable. But realistically speaking, I would do that only if there's a clear distinction of the product where there's 3 very related tracks. Else, it will require lots of coordination between multiple teams. I would start off with 2 teams, and when they are matured and consistent, then could consider reform them, get them to pair with someone from another team, learning will happen and the team will be stronger. 
    2. Putting all the QA in a team are suggesting the team will only do QA. There's nothing wrong by splitting the team by component/ role, but there's indept discussion on this... You may find it useful...

      https://www.scrum.org/forum/scrum-forum/5563/feature-teams-vs-component-teams
  2. Yes, this is the recommended way to run a Daily Standup.... for a start.... 

    Once the team are getting familiar and see the benefits of the standup, we can use different methods to achieve the same, if not better, value out of the activity. Below is an article that talks about Shu Ha Ri on Agile Adoption Pattern. You might find this articule useful. 

    https://www.solutionsiq.com/resource/blog-post/shuhari-agile-adoption-pattern/

Lastly, my advise is to continue to experiment and try out different ways and method with your team.Scrum guide serve as a good starting point (but stick with the principles) for a new team, each team will eventually evolve and each will have their characteristics and ways to run certain ceremonies. Have fun, and don't stop experimenting! 

 
New Post 3/6/2019 4:09 PM
User is offline simonteo
3 posts
No Ranking


Re: Basic questions 
 simonteo wrote
  1. In my world, we generally do not assign task to indiviual / pair during planning. We look at the prioritized product backlog and do estimation for each top stories. And based on the past sprint velocities and commitment from each members, we will decide which stories will go into the Sprint Backlog. 

    During the standup, individual or pair will pick the story that they would like to work on.

    1. Scrum dictate that each team should be 3-9 team. 

      Below there's an article that study the ideal size for a scrum team to be productive. 

      https://agilepainrelief.com/notesfromatooluser/2016/10/choosing-the-team-size-in-scrum.html#.XH-JTs8zZQI

      For a team size of 3, it should be expected to perform as a Feature Team (where all members are cross-functional and cross-component). QA role can do dev, Developer role can do QA. 

      As such, dividing them into 3 teams (4,3,3) is totally workable. But realistically speaking, I would do that only if there's a clear distinction of the product where there's 3 very UNrelated tracks. Else, it will require lots of coordination between multiple teams. I would start off with 2 teams, and when they are matured and consistent, then could consider reform them, get them to pair with someone from another team, learning will happen and the team will be stronger. 
    2. Putting all the QA in a team are suggesting the team will only do QA. There's nothing wrong by splitting the team by component/ role, but there's indepth discussion on this... You may find it useful...

      https://www.scrum.org/forum/scrum-forum/5563/feature-teams-vs-component-teams
  2. Yes, this is the recommended way to run a Daily Standup.... for a start.... 

    Once the team are getting familiar and see the benefits of the standup, we can use different methods to achieve the same, if not better, value out of the activity. Below is an article that talks about Shu Ha Ri on Agile Adoption Pattern. You might find this articule useful. 

    https://www.solutionsiq.com/resource/blog-post/shuhari-agile-adoption-pattern/

Lastly, my advise is to continue to experiment and try out different ways and method with your team.Scrum guide serve as a good starting point (but stick with the principles) for a new team, each team will eventually evolve and each will have their characteristics and ways to run certain ceremonies. Have fun, and don't stop experimenting! 


 

Corrected some mistakes

 
Previous Previous
 
Next Next
  Modern Analyst Forums  Business and Sy...  Agile Analysis ...  Basic questions

Community Blog - Latest Posts

Trividh Patel, CBAP
Trividh Patel, CBAP
At first, I wanted to tell people how they should go about getting their IIBA certification. But then I thought the best way to do this is by actually telling “how did I achieve my own CBAP?” So, friends here is my story. I started working as Business Analyst in 2002. I have used multiple elicitation techniques (such as interviewing,...
0 Responses
Ekaterina Barabash
Ekaterina Barabash
I address my thoughts to those who are in IT management for whom the terms such as quality of project implementation development and profitability indicators of the company are important.  And it is also addressed to business analysts whose daily routine is the process of communication with Customer. A little about myself first. The last 8...
0 Responses
Dan Tasker
Dan Tasker
I have long been a believer in the saying “Context is everything.” As a business analyst dealing with business users, understanding the context of the topic of discussion is essential. In thinking about what constitutes quality requirements it occurred to me that there are a number of additional contexts that play a role. Examples inclu...
1 Responses




Latest Articles

Requirement Elicitation: Stories Are Not Requirements
Mar 17, 2019
0 Comments
  One of the three activities encompassed under Requirements Analysis is the process of ‘ Requirements elicitation’. IIBA’s de...
Featured Digital Library Resources 
Copyright 2006-2019 by Modern Analyst Media LLC