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?
0
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.
4
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.
8
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