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?


3 Answers 3


If you are doing scrum, you should have a Product Owner, no? It's his or her job to prioritize the stuff that comes along and manage the relationship with the customers. That said, the product owner should not be adding items to a sprint unless the team agrees to it and that there are items that have not been started yet and can be pushed out of the sprint to compensate.

If the new customer results in a second product owner, that makes for a second project. In that case you should form a second team and create a prioritized backlog for the new project.

If you are running into a lot of this, you might look at kanban as an alternative to scrum.

  • +1 for "if there are one or two product owners" and the kanban alternative
    – k3b
    Jan 6, 2013 at 9:19
  • Every customer is independent product owner. Usually we have 3-4 customers at the same time. Our team is about 6-7 developers so we can't split them in 4 teams. By now we just do most urgent features first. And if new customer demo is required, part of the team begins preparing to it and then turn back to planned features.
    – andrey
    Jan 6, 2013 at 9:24
  • +1 for you might look at kanban as an alternative to scrum, scrum isn't a good fit for every business, if pre-sales work requires you to re-prioritize at short notice, maybe it isn't a good fit for you. Jan 7, 2013 at 1:49
  • second product owner - I was under the impression the number of product owners should correspond to the number of products, not to the number of customers. Of course, if you create a second branch of your product (perhaps a "demo" branch), and treat it completely as a separate product and work at this branch with a separated team, then two product owners make sense, but isn't this causing way too much organizational overhead for this kind of "1 week" situation, just for the sake of sticking formally to the Scrum method?
    – Doc Brown
    Jan 7, 2013 at 9:18

No customer worth having wants less than a week worth of programming.

Show them what you can do, and say you can modify it to do what they want once they sign the deal. Then schedule it for some future sprint and get it done.

  • This may be not a week but day or two. Ignoring his needs we may lose him, because competitors will have this features. And we can't afford lossing him, because every new customer is valuable
    – andrey
    Jan 5, 2013 at 22:20
  • 7
    @andrey - if you're losing customers to competitors with a day or two's worth of features why are you not spending your sprint implementing those features? If you're not working on them, then whatever features you are working on will gain you more/better customers. Trust your prioritization. Juggling things is wasteful overhead.
    – Telastyn
    Jan 5, 2013 at 22:30
  • This is what overtime is for. Knock up a prototype, make sure your manager (at the very least) knows you're going beyond the call of duty. If it happens often allocate some time in your sprint for this eventuality.
    – James
    Jan 6, 2013 at 3:54
  • -1, this answer means "stick to the formal agile method whatever comes". I am pretty sure this is not what the "agile inventors" had in mind. And the other misconception here is that the worth of a feature for a customer is directly related to the programming effort.
    – Doc Brown
    Jan 6, 2013 at 9:22
  • 1
    this smells suspiciously like Sales or Marketing trying to tell Engineering how to do their job - it could be argued that your answer is Engineering trying to tell Sales and Marketing how to do their job Jan 7, 2013 at 1:50

There are times when the marketing promise a potential customer having a feature that is not implemented yet :-(

From mangement point of view the "new feature or customer will not buy" is similar to a "critical production bug that must be fixed and deliverd as soon as possible" .

For this emergency situation i suggest

  • stop the sprint and
  • stop working on the current development-branch and
  • create a new emergencybranch that originates from the last released-stable-fulltested-production-branch and
  • fix the bug (or in your case create the "new customer" feature)
  • do the testes, deployment, create patches,... (for bugfix only)
  • if every thing works ok this bugfix/feature is merged into the stopped development branch and the sprint is either resumed or canceld_with_new_sprint_planning.

Your management should be aware this workflow is costly and should only be used in real emergency situations.

  • +1 for essentially suggesting that this is a "drop everything, all hands on deck to resolve" situation. Both because it rarely really is such a situation, and because treating it like one will make the product owner understand the impact it has. Jan 6, 2013 at 13:44

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.