JIT requirements with scrum
The true beauty of scrum dawned on me again. This is the second time I am in the role of product owner for a relatively small project. The customer is not so much into internet so I have to pull the information out of them.
It also implies that the customer does not clear view on ‘linked’ and related elements that might also be sucked in into the changes.
Again scrum aims to have the specs ready before the team has to work on them. As you try to figure out the complete scope of the project and who your stakeholders are you might not be able to get the job done on time. This is especially the case in short project where your horizon at the start of the project is already on the end of the project. This means you’ll have to find a way to get everything just in time.
What I found was that this mission impossible is well solvable with the help of the team.
Well first of all the need to have enough information to make a correct estimation, as scrum dictates. This is the basic and there is no way of skipping that. However you can play around with the amount detail you provide. How much is enough to get the job done.
During the sprint the team will (especially in this case) start asking questions, questions you couldn’t have possibly imagined. This is where jit requirements kick in.
You cannot foresee all the elements. Even if you try you would still be off a third of the time. This time is better spent when the team actually needs it.
So bottom line:
-Try to get all stakeholders in the picture
-Identify problem areas and make sure everyone is aware of that (start rubbing the painful spots as early a possible and keep them flexible)
-Try to gather information, just enough for the team to make an estimation and start working
-Accept questions as often as needed..