How do I explain to my team “there is no problem if the requirements need to change after a sprint?”

Question

My team is very inexperienced in how manager our only work and how much time is necessary to spend in some tasks. So many sample things like just develop what our client needs and show it for her (like agile methodology) are transformed into boring and unnecessary meetings which some members try to guess what the customer needs rather than simply delivering a basic version.

We don't have a leader and I don't know exactly how tell "please, stop make so many software requirements specification and let's code that".

Of course is so important know all the software specifications/requirements but we are spend so many time in this steps (the project will be delivered on 2 months), like define all stakeholders and what they impact in project (why? the client just need approve) and I hope they don't want to do class diagram e uml diagram.

How explain for my team "there is no problem if the requirements need to change after a sprint and is normal if some things go wrong in this process, please let's code"?

Answer 1

There may be many stakeholders in the real world, but as far as the developers are concerned, there is only one: The product manager who was selected by the companies involved to have the responsibility that the product created is what the stakeholders need. If that person isn't there or fails to do their job, the project is going to fail.

The product manager creates individual tasks that are achievable, and have an acceptance criterion, and prioritises them. The team decides which tasks they will do during a sprint, based on reasonable estimates for the duration of tasks, taking into account priorities and dependencies. And then the team does its best to deliver these tasks during a sprint.

Now if the product manager changes their mind, and the work done in the sprint that was asked for turns out to be useless, then the development team doesn't have to worry in the sense that it isn't their fault. It's still a waste of time that will affect the project.

Answer 2

Close involvement by a primary stakeholder (the "customer representative") is going to be required to make this work. Here's why:

1. Requirements must be accompanied by an acceptance test that, when executed, unambiguously proves that the requirement has been satisfied. If it isn't accompanied by an acceptance test, it's not a requirement; it's a wish.

2. If you're doing this the "agile" way, you only have time for about six sprints for the entire project. Without close, ongoing feedback from the customer, it can't be done.

3. You are almost certainly underestimating the scope of the work. Two months is not a lot of time. Your last paragraph, "there is no problem if the requirements need to change after a sprint" pretty much guarantees that it's not going to get done in 2 months.

4. If a requirement changes due to stakeholder involvement, you need to get approval for extending the amount of time to completion.

Answer 3

You mention that you are using Sprints, which allows me to assume you are impmlementing an Agile approach such as Scrum. If this is the case, you should have a Product Owner (PO) working with the team to clarify any questions that the time might have, during sprint planning, and throughout the sprint. The purpose of the PO role is to liaise with the stakeholder/customer and the team. Under no cirumstances should the team be making assumptions or deicsions on what the customer will want.

If you have a PO in place, then the PO is the only one who can make these decisions for the team and should prioritise these decisions accordingly.

Secondly, when you perform sprint planning, it is important to agree on a sprint goal, with input from the PO and the team - this helps to keep the team focussed on what is important and helps to prevent the team from going off on a tangent.

Finally, The sprint goal can influence how stories are broken up - and if you are struggling to keep the team focussed, spend more time breaking stories into sub tasks to ensure that both the team and PO are on the same page. You can then encourage the team to focus only on working on these subtasks