-1

The company I work for uses scrum methodology, Before each sprint, we do a sprint planning, sprints are 3 weeks long.

I find myself many times getting items, I should break down to tasks and PRICE it with development / QA days, as that's what we do in the planning stage, that I simply have no idea how long it would take and there's no way that without a proper drill down to code I will be able to know it.

I explained to the R&D manager, that I cannot commit on "DONE" for such items, I can however commit on the research time it would take me to understand what should be done (E.g. drill down to code, provide fun specs, etc).

Is this the correct approach or maybe there's a better one?

Answers would be appreciated.

acutesoftware
  • 1,091
  • 3
  • 14
  • 33
Y.S
  • 1,860
  • 3
  • 17
  • 30

1 Answers1

2

There are two approaches you can take. One is to do what is called 'backlog refinement'. With that, you get visibility of the likely work in the next sprint several days in advance of the planning meeting. You can then spend some time investigating prior to the planning meeting and make sure you are ready.

Second approach is to do what is called a 'spike'. In this you don't commit to do the story in the next sprint, but you do commit to spend some time investigating so that you will be ready to do the story in the next sprint. Typically people timebox the spike (say a couple of hours or 1 day maximum). This second approach only works if the Product Owner doesn't mind the story being delayed for at least one sprint.

Barnaby Golden
  • 4,176
  • 1
  • 23
  • 28