2

I would like to know if anyone is in a similar situation working as part of a SCRUM team -

The majority of our team are R&D staff, or academic research staff. We work in what might be called "bleeding edge" research areas, across multiple disciplines. Various (maybe all) members at some point have struggled with creating backlogs. The reason being is that because so much of what they do is unknown in advance, they generally end up doing a small piece of work, in which what must come next becomes clearer (multiple new stories per exploratory work), in which it makes sense to work on "what comes next" almost immediately i.e. not wait for the next 2 week sprint.

Give that the work our team undertake is not repetative, with iterations of unknown work that are required to be worked on "as they come", does anyone have any tips on how to plan a backlog multiple sprints in advance.

To give an example - one day a member of staff might run an experiment in a lab on some the effects of some radioactive material on a tissue sample, of which the results need to be intepretated. These stories can generally be written in advance no problem. But depending on the analysis, some theoretical work might need to be done to rethink the problem, further experiments might need to be done to confirm a finding (an easy win in terms of generating new stories), or altering the experiment format is necessary. It is often the case that new variables / methods / software / hardware / even the fundamental problem may change upon the initial anaylsis - which yes the intitial phase can happen over a mere few days so I'd say one fifth of the stories could be planned per sprint.

It's beginning to get really tough committing to even a one week sprint as we can't commit a week's worth of user stories. Any suggestions would be great.

2

2 Answers 2

6

Scrum, and fixed length sprints may not be the answer. Maybe the focus should be on the ability to groom stories and develop a backlog (when feasible) and to limit work in progress, so that the team members aren't overwhelmed. In such a case, Kanban might be a better solution.

It's important to make the methodology fit people. It is sort of the antithesis of Agile to value process over people :-)

1
  • I suspect and agree that something more flexible than SCRUM may be needed. Will look into Kanaban. Apr 11, 2018 at 22:17
1

I imagine that even though you can't really plan two week sprints you do have milestones/epics and they probably have deadlines. So I suggest to link tasks, work and backlog around those and trial different options.

It seems like having a good description of the tasks will be very helpful. Every-time someone needs to do a new task, they should log it and add the relevant data to it (experiment? second iteration of the results of another? new research? time that it took, project, etc). Be as specific as possible. Once you have enough data, you would be able to understand what's your team spending their time on, how much time on average on each type of task, and then you can think about the best planning strategy and also the pace of your team.

3
  • So as I understand it - we should aim to figure out what an "average sprint" entails for us such as what take usually get done and how long they take, and then when it comes to a new sprint - even if we can't plan what we will actually have to do, at could at least write estimated stories with estimated times? Apr 11, 2018 at 22:08
  • I think so. And you can make modifications as things change. Be careful of not overspending time on this tasks, think about the trade offs, you don't want to spend 50% of your researchers time on this for example :). Apr 11, 2018 at 22:11
  • Maybe you don't even need sprints. Perhaps you can just find an ongoing planning strategy and work around finishing milestones/epics. Apr 11, 2018 at 22:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.