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

 
New Post 5/31/2019 6:21 AM
User is offline Stewart F
119 posts
7th Level Poster


Re: Basic questions 

 

I think what Simon said is quite right. One of the best features in Scrum/Agile is that there is no real 'right or wrong'. If your team find Stand-ups a bit counter-productive, then don't have them. Find a more suitable way to get daily updates. As a Senior BA, I use to sit with my Dev team - so I knew where things were, what was happening and when they had questions. It also allowed Devs and Testers to speak easily and openly to me, as I was sat with them. You pick up problems far quicker and you can resolve them before they turn into a disaster.

The point being - do it how it works best for you. If you get all the information your team needs to work correctly, it cant be wrong.

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

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