Re: [scrumdevelopment] Sprint planning and committing to work
- Hi,Since you're estimating in story points, you're already estimating all the work necessary to finish each story in the sprint. This includes BA and testing work. So you're doing fine:-)I would make sure that testers are also voting for the estimates in the planning meeting. Since you're estimating relatively, they can focus mostly on the testing parts, but including them in making the estimates ensures that their considerations are taken into account in the conversation about the story. And sometimes you simply have stories that have relatively more testing necessary than development, and that should be reflected in the estimate.WouterOn Tue, Aug 31, 2010 at 2:00 PM, scrumnoob <scrumnoob@...> wrote:
I think this might generate more questions back to me, but...
I have a team comprising 2 test analysts, 2 BA and at the moment 4-5 developers. This will grow soon and I will be faced with parallel sprints but thats another topic....but I can see the team size maybe an issue already.
My defaul behaviour was to estimate (in story points) each story and commit to the work the developers thought they could get done, we have 5 sprints behind us so this is proving quite accurate. What I dont do is account for the BA/TA work and estimate the testing effort for example of each story. Currently we hope (I know!) that the ratio of tester to developer is "about right" and we will test the work before the end of the sprint (functional test only).
Does anyone estimate the BA/TA effort for sprints?
For the BA I would say I am comfortable ignoring this as the story needs to be ready in enough detail for the developer to pick it up. For the TA I am less sure of the merits/demerits of estimating their work and then including in burndown/velocity analysis.