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

Dan Tasker
Dan Tasker
  In Part 1 of this series it was stated that the overall objective of these articles is to improve the quality of requirements produced by business analysts. Following the adage that “Context is Everything” it established that a number of different contexts...
4 Responses
Arash
Arash
It may sound routine, but the importance of operational decisions cannot be underestimated. After all, not a day goes by without even the smallest business making dozens, if not hundreds of operational decisions that may affect the bottom line. Elevate these to large scale companies and we are talking thousands, if not millions of actions that impa...
0 Responses
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,...
1 Responses




Latest Articles

4 Things To Consider Before Hiring A Business Analyst For Your Project
May 19, 2019
0 Comments
I like to compare a business analyst to an architect. While the architect asks questions about design, budget, and personal preferences of a person wh...
Copyright 2006-2019 by Modern Analyst Media LLC