Once more as a reminder:

Principles behind the Agile Manifesto

• Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
• Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
• Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
• Business people and developers must work together daily throughout the project.
• Build projects around motivated individuals.
• Give them the environment and support they need, and trust them to get the job done.
• The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
• Working software is the primary measure of progress.
• Agile processes promote sustainable development.
• The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
• Continuous attention to technical excellence and good design enhances agility.
• Simplicity–the art of maximizing the amount of work not done–is essential.
• The best architectures, requirements, and designs emerge from self-organizing teams.
• At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

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.

How?

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

[openbook booknumber=”9780321579362″]

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…

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

[openbook booknumber=”1934356433″]

I haven’t much time on programming lately because i am now more involved in processes and how to optimize software development. Now there are a lot of tools on the market that claim to have the perfect solution for almost anything.. but i was looking more into a tool that could help me with creating a proper backlog for the scrum projects.
On of the reasons most tools are crap, is because they are.. but also it does not leave any space to fill out domain specific information on what might be of some interest to the backlog.. until i ran into explainpmt which is open source, easy to use, just enough functionality and so on..

I could have gone for the good old excel/spreadsheet but was not very appealing to me either.

After reading a small review on explainmpt by Jake Dempsey, i was convinced to start using this tool.

Explainpmt is written in ruby.. so immediately i was enthusiastic.. and once more the install on ubuntu went almost smooth-less and the hickups i did encounter were quickly solved by the excellent user documentation on ubuntu or ruby sites…. just great