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..

Velocity measuring on individuals

In scrum the ideal world would be a world where a team is homogeneous, fully commited and every team member is multi-disciplinary such that the behaviour of the team becomes more predictable. However in real life, and especially in a setting where waterfall is the fundament you have to work on, this is usually not the case, facing members working part-time, having holidays and getting sick sometimes but most of all having different backgrounds.

Your goal as scrummaster is to optimize the productivity of the team. This means you have to suggest and steer the team in the process where needed in order for them to work as optimal as possible. This suggesting and steering is probably based on intuition, best practices and so on. As scrum is just a set of guidelines and rules there is a lot of open space on how to cope and handle situations like these. One could jump into detail and/or work on a higher level, inspect and adjust, try new methods etc. etc..

The problem is that sooner or later some manager or CEO would like to know what is happening and in which direction the project is going or what can be done to improve the project.
Usually the velocity of the previous sprint will give a good insight on what can be accomplished on product backlog (remember in the ideal scrum world it would be). The uncertainty is that the balance between all disciplines of each story is different. Some are real tech stories and whereas some are design/user interaction stories. This makes it hard to predict the outcome thus increasing the risks involved.

Now what can be done to reduce this risk? The most obvious is knowing what is happening: who is doing what at which velocity such that team velocity becomes more predictable. This implies gathering data, analysing, reporting and so on.

As we start walking down this road i get the creepy feeling something is wrong since we like to keep things simple and cut waste (reports). Focus on being productive is what we want right?
Using this method also reduces the agility in which one assumes it is ok not to know everything right now.

On the other hand:
Knowing the velocity of each team member provides better individual feedback and enables adjustment on the velocity on each member as each team member should/could work on roughly the same velocity, making the team more homogeneous.

Probably the best option would be to apply the statistics when:
– You got the impression the balance between the different fields/disciplines is off
– There is a need to give a more accurate estimate on the product backlog and identify risks.
– More accurate estimates on a single story
– Times off fluctuation in availability (holidays)

If the outcome on the individuals shows big gabs, then perhaps it is time to discuss what the meaning of a storypoint is and what causes these differences.
-are too many disturbances?
-are some members working harder?
-is the concept of a storypoint still clear?
-are the estimates during the sprint planning correct?

Too be continued…

The interview

Today i tried a new exercise for a retrospective. I name it the interview.
Setting: 1 team-member is interviewed by other team-members such that the interviewee wants to explain the sprint, process or something that needs to be discussed.

The point is that emotions and remarks from the interviewee should be captured as that is being used as input for the next exercise. Now in a small group you can assign a few people as a monitor group. while the others are taking the interview.

In this case the team was small so the interviewers also were assigned with the task of monitoring. As input for the interview i used the agile manifesto printed on small cards so each interviewer had to question the interviewee on this specific topic. After 5 minutes i would let the group rotate and thereby enabling everyone to once be the interviewee and interviewer.

The output was written on sticky notes so we could place them on a flap over later on.

The results: the quantity of the output was overwhelming. We had enough material to work on in deciding what to do and categorizing the items. Of course i was interested in the opinion of the team. Their remarks where that the technique for retrieving information was good, but the topics where to general for the sprint and therefor the topics where more suitable for a project retro.

Goals: Besides the obvious goal for this exercise was to retrieve information.
However i also had an hidden agenda.
First of all 1 wanted to make the team more familiar with the agile manifesto and
Secondly i wanted them to work together on their perspective on scrum.

So although i failed to do a retro for this sprint, i do feel the team learned something.

Removing story in sprint

We have a sprint workload just enough to complete within the sprint. Now the customer wishes to remove a story, which will result in too less work for the sprint.
The length of the sprint is 2 weeks of which 2 days have gone by so far.
Normally another story on the product backlog could be the replacement. However the product backlog is empty so there is nothing to fill it up with.
So options:
Continue as is and building the story which then needs to be removed afterwards.
Removing the story ending up with idle time.
Removing and shortening the sprint time.

We want to agile, so definitely the first 2 options are a no go. On the other hand we don’t want to cheat on the process….