2

Our team is going to adopt scrum and agile technics. We've got a product, which we develop for multiple customers. This customers supplied us with necessary requirements, so everithing is fine to adopt agile techinics.

But at some moment (for example during sprint), new customer apears, and he wants to get a demo of product slightly different from what we have now. This may be some new features or minor differences in behavior. And he wants to get this demo for example during the week. It is very important to show that our product supports this features (because otherwise he will address to our competitors), so we have to develop this features (may be partly) during the week.

How we must handle this sort of features with agile? Move them to current sprint backlog? Or split one team to two and create another sprint? Or may be there is another way?

andrey
  • 179
  • 1
  • 6
  • 1
    As more of a whiteboard question than a code question, maybe `programmers.stackexchange.com` would be a better fit? – DSM Jan 05 '13 at 21:51

2 Answers2

2

I generally agree with jessehouwing's answer. If the problem you outline is uncommon, then what he has answered makes sense. IF this will be a common occurrence, sprinting may not be the answer you are looking for. A more flexible approach to this problem would be Kanban. In Kanban you work story by story instead of planning an entire sprint. This style works nicely for teams who have regularly changing priorities.

Steve Miskiewicz
  • 1,114
  • 1
  • 10
  • 23
  • 1
    Agreed. Using a pull system would be more suitable, but the same problems would still occur. You'll still need to prioritize and you'll still dlay other work you had expected to finish. The way it manifests is different though. I expect that Kanan might not be the right answer here either, I think a better approach to the sales and customer question handling might be in order. Having constant high priority interruptions is unwanted in both Kanban and in Scrum, though Kanban handles them more elegantly. – jessehouwing Jan 06 '13 at 19:19
1

Scrum allows you to re-negotiate the sprint between the Product Owner and the Development team, so if this item is very very important, the PO can propose the team to swap out already planned, but not started, work of the same size.

Or when the amount of work will consume all time remaining in the sprint, the PO can cancel the current sprint and call for a new sprint, with these changes as the most important items. All undone work in the cancelled sprint should be considered lost.

If these kinds of mid-sprint-changes happen frequently, you might want to reserve some capacity to accommodate these types of requests. Just reduce the number of story points you'll take on during the sprint planning meeting. Or, depending on your current sprint length, you might want to reduce the number of days in a sprint to a week or something, that way you'll reduce the risk when these types of changes are required.

jessehouwing
  • 106,458
  • 22
  • 256
  • 341
  • Every customer is independent product owner. And usually we have 3-4 different customers at the same time. So may be project manager must decide to change sprint. – andrey Jan 06 '13 at 09:51
  • You can only have one product owner in a scrum team. having multiple will screw you up. Makign the Project Manager a Product Owner might work, but he will probably not be able to provide critical insight in the wants and needs without going back to the 'real' product owners. Unless you have a product you're building and selling, then there is probably someone in your organisation who truly knows what he or she wants and which customers will have to wait and which ones will get priority. – jessehouwing Jan 06 '13 at 13:29
  • We've got something like this, there is one who involved in every customer problem and decide which customer is first-priority – andrey Jan 06 '13 at 19:09