Work Done by Scrum Team members during Scrum
Lets take a normal team where we have 1 BA, 3-4 Dev, 2-3 QA.
When a scrum starts, BA will refine the USs & explain to the team. Dev will code and post that QA will test. So my questions is :
- Once BA has explained the USs in initial 1-2 days of the iteration, what does he/she do for the remaining iteration? (of course he/she will work with Product Owner on the backlog but how will that be captured to justify his full iteration work)
- When Dev have finished the coding and testers start testing, what will Dev be doing for remaining part of the iteration if no one else in team needs any help ?
- In the teams I have seen, they have a rule to have 1 Story Point = 8 hrs of work. So in 1 iteration, a max of 8 story point worth of work by each person can be taken. But if a US needs Dev and test both, then even if the US needs full iteration to complete but the effort will be divided between Dev and test. So they should estimate it as 8 or maybe like 4 since each of them will be spending equal time in doing their activities.
The Scrum Guide says:
The Scrum Team consists of one Scrum Master, one Product Owner, and Developers. Within a Scrum Team, there are no sub-teams or hierarchies. It is a cohesive unit of professionals focused on one objective at a time, the Product Goal.
Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint. They are also self-managing, meaning they internally decide who does what, when, and how.
Is the team you describe self-managing well -- in terms of who does what, when, and how -- so sub-teams are avoided and focus is achieved?
Hello,
As Ian Mitchell discussed, Scrum Team consists of PO, Developers, and Scrum Master.
1) Your first query regarding BA : BA will contantly work with PO in the current iteration (ex. in Sprint Planning, PBR etc.) also He will work with PO to prioritize PB and helping him for User Story and Acceptance Criteria.
2) When Dev have finished the coding and testers start testing, a developer can work on his remaining assigned work items, and if all the work items finished before time then after discussion with PO, developers can take more work items from PB. Also, developers can resolve bugs, code review in buffer time.
3) 1 Story Point = 8 hrs of work: It is the wrong concept. We can't compare Story Points with Hours.
We are giving story points based on the Amount of work, complexity, Risk, Dependancy etc. It is a relative size estimation technique. I think you should read some more articles regarding story points.
You explained waterfall very well. Yes, waterfall because agile practices do not pass through phase gates. To answer your questions.
If the Business Analyst does not have any analyst work, why couldn't they help the Quality Assurance prepare for their testing? Why couldn't they actually help with testing? Who better to ensure that the story statement is actually satisfied than the one that is communicating that statement to the team?
Why couldn't the developers that "have no work" be helping with the testing? Possibly have them write some automated integration or end-to-end tests? Have them help the Business Analyst in refining Product Backlog items? Remember that refinement is an ongoing activity and not a scheduled meeting.
As for the Story Points, that is entirely up to your team to decide. The Scrum framework does not mention anything about User Stories or Story Points. It mentions Items and an estimate. How you do document the Item and do the estimate is part of the process you decide upon. Process is not dictated in Scrum. This is the last paragraph of the Scrum Guide's section on the Purpose of the Scrum Guide
As Scrum is being used, patterns, processes, and insights that fit the Scrum framework as described in this document, may be found, applied and devised. Their description is beyond the purpose of the Scrum Guide because they are context sensitive and differ widely between Scrum uses. Such tactics for using within the Scrum framework vary widely and are described elsewhere.
So ask your team how they want to estimate the situation you described. After all, they are the ones who decided that points would equal hours. That is how Story Points first started in eXtreme Programming but they evolved from there to be a relative estimation of effort.