Feature driven Project Management
In Agile projects, project management effort is mostly focused on features. An Agile project may target a fixed release date and have a fixed budget, but the exact set of features that is delivered will be refined along the way. Managing the tasks to implement these features is left to the people that perform them. The effort of a Product Owner is focused on prioritizing and refining features that the Agile teams will work on.

This approach has proven to be much more effective in delivering software within time and budgetary constraints. However, the ultimate goal of software development should not be to deliver features within time and budget.

Value driven Project Management
Teams build features that add Value to the business. Examples of business objectives are “increase market share”, or “increase customer satisfaction”. Underlying such high level goals, there usually are lower level goals such as “increase the number of visitors to our website”, or “increase the percentage of visitors that buy a product”.

Currently, most people on Agile projects have a good understanding of the cost of features, but not of the Value that is delivered by these features. What do you think is more interesting to know about a software release:

• “A sum of 400 story points worth of features has been delivered”, or
• “The SEO optimization in the release resulted in a 30% increase in the number of visitors to our website, which resulted in an increase of market share by 5%”?

To plan for Value, business objectives should be expressed explicitly, they should be quantified and they should be measured. For the features we build, we should be explicit in how and to what extent we expect them to achieve these business objectives. Using measured data after releasing new or improved features, it should be validated whether they have the expected results.

For a team to be effective in helping to achieve business objectives, it is essential to have a shared understanding of them. Only then the knowledge and creativity of people that work on a project can be used to come up with the best ways to achieve them. Only then can it be validated which features are really adding most value to the stakeholders.

Note that the idea of Value driven project management is not at all new. Agile pioneer Tom Gilb is preaching this ever since he pioneered doing iterative software development. Together with his son Kai they are on an endless quest to convince the world that this is the way to do project management if you want to be competitive.

I think the Agile community will catch up with them eventually. In the evolution of project management, moving from Task driven to Value driven just proved to be too big a step. The current Feature driven approach is a necessary intermediate step. To be competitive, you should want to be in the forefront. It’s time to take the next step. It’s time for Value driven project management!

Do the following statements describe the situation of your team?
- Little is done about problems discussed in Retrospectives.
- Sprint Reviews have no impact on what is build in subsequent sprints.

If so, you may be interested to read my article on the Scrum Alliance website: Effective Retrospectives & Reviews.

1. Collaborate with the Product Owner to add improvement items to the Product Backlog.
In a Scrum project, the Product Owner has to balance all stakeholders that want to use the team’s capacity to achieve their goals. Stakeholders can be end-users, an operations department, a marketing department and so on, but the team itself is also a stakeholder. The work that a team identifies to improve itself can be prioritized by the Product Owner on the Product Backlog just like all other planned work for the team. It should be possible for the team to explain the advantages for the other stakeholders, or else it may not be such a good idea after all.

I have seen teams that identify significant amounts of work in retrospectives that would really pay off, but plan to do it next to the ‘normal’ work from the Product Backlog. If the team has an established velocity that the Product Owner expects to be continued, the team will just not find the time to do the ‘extra’ work. This typically happens to things like big refactorings, improvements to the continuous integration build and the introduction of automated functional tests. If such work is added to the Product Backlog, it will be estimated and prioritized together with the other planned work that the Product Owner wants the team to do. Once it is then picked up in a Sprint, the team will focus on it and get it done.

2. Maintain working agreements and update them as the outcome of retrospectives.
It’s a good idea to be explicit about the things that the team has agreed upon. In his blog Team norming and chartering, Martin van Vliet describes how to establish such agreements. The resulting agreements should be prominently posted (on the wall or a Wiki) and be visible to everyone. These agreements provide the basis for effective team work and can be referred to in the case of disagreements. This is an important step in the evolution of ‘just a group of people’ to a team.

If you maintain working agreements, you can hold each other accountable and you can inspect and adapt to make improvements on them. A typical subject of working agreements is how to deal with bugs that are found in a sprint. For example: Are they entered in a bug tracking system or only put on the Scrum Board? How much context information is added to bug reports? Do bugs always have priority over other tasks on the Sprint Backlog? Another common subject of working agreements is which engineering practices the team will follow and to what extend: Will team members always do pair programming or only when they choose to do so? Will they always do test driven development The outcome of a retrospectives can be to change one or more working agreements.

3. Maintain a Definition of Done and reflect on it in retrospectives.
Many teams are not explicit in what their Definition of Done is. In a Definition of Done, a team specifies the general acceptance criteria for features that are delivered in a Sprint. For example: Should each feature be documented? Within which intervals should requests be handled? Should features be formally accepted by the business?

There are trade-offs in how ambitious a team can be in in its Definition of Done. A retrospective is a good time to reflect on this. For example, part of the Definition of Done of a team that I coached was that all features should be tested on several versions of several web browsers. When the set of browsers was defined for which testing should be done, the Product Owner had no idea how much work this would bring about. In a retrospective, it was identified that testing for all these browsers was the main bottleneck for getting features Done. The Product Owner then decided that tests needed only to be done for a smaller set of browsers, based on usage statistics. The Definition of Done was changed accordingly and the team’s velocity increased significantly.

4. Maintain reports of retrospective outcomes and verify whether anticipated improvements took place.
My final advise is to inspect and adapt on the outcomes of retrospectives. You can never be sure whether a change actually results in the desired effect unless you verify it after the change has taken place. To be able to do this, keep track on the decisions that have been made in retrospectives, for example on a wiki. Then regularly look back on them to discuss results of changes to the velocity and quality of work. For some teams, a fixed item on the agenda of every retrospective is to reflect on the results of decisions from the previous retrospective.

I hope that these advises will help some ScrumMasters to facilitate retrospectives that lead to higher velocity and higher quality deliverables of their teams.

In this blog, I discuss on how to facilitate the estimation of Product Backlog items so that the Product Owner can do release planning.

As Mike Cohn has pointed out in his excellent book Agile Estimating and Planning, planning is done at three levels in Agile projects:

• Daily planning;
• Iteration planning;
• Release planning.

In most Scrum projects, the first two of these levels get the attention they deserve: Daily planning is done at the Daily Scrum, Iteration planning is done at the Sprint Planning Meeting. The third level of planning is where things often get messier. In most projects, there is a need for a planning horizon that is further away than one Sprint. For example, a marketing campaign is planned three months from now and the Product Owner wants to know what features can be expected to be done by then. If the project uses user stories with story point estimates, the following information is needed:

• The velocity of the team(s): how many story points are done each Sprint?
• Estimates in story points for at least all user stories that have a chance of being done before the release date.

I have seen that people struggle with this because Scrum has traditionally not been explicit on when and how to establish estimates for user stories. In many Scrum projects, the only time when estimating is done is the Sprint Planning Meeting. Sometimes user stories are estimated in story points, but these estimates are given only to the same set of user stories for which tasks are identified and estimated subsequently. This really defies the purpose of story point estimates. The team might as well omit story point estimates altogether because the task estimates should be enough to check if it is viable to do the planned work in one Sprint.

My advice is to estimate user stories in Backlog Refinement Meetings separate form Planning Meetings. In these meetings, larger sets of user stories can be estimated than in a Planning Meeting because only just enough detail need to be discussed to estimate user stories relative to each other. At least the product owner and team representatives of all the disciplines that work on the Product Backlog must be present. Especially if multiple teams work from one product backlog, it is not always feasible to include everyone in every session.

Backlog Refinement Meetings are also a good place to discuss how to split up larger user stories into smaller ones and identify user stories that need further clarification. This is the reason why I prefer the term Backlog Refinement Meeting instead of Estimation Meeting. In Sprint Planning Meetings, only estimated user stories are discussed that have been identified to be READY for the team to start to work on.

The best and most widely used technique to estimate Product Backlog items is to estimate in story points using planning poker. If many items need to be estimated in a short time you can also consider an alternative approach that I have lined out in an earlier blog: let the team order them all at once on a horizontal scale and then assign story points.

Now that we have discussed the Backlog Refinement Meeting, note that there are strong analogies between Iteration planning and Release planning, detailed out in the following table:

With this blog I hope that I have helped some ScrumMasters a little further in applying Scrum to do projects successfully. I will now start to think about by next Tip for ScrumMasters …

• additional acceptance or integration testing is needed that can not (yet) be done within the sprint;
• user stories have dependencies on hardware of software from an external party that is not yet available;
• minimal marketable features are bigger than what can be produced in one sprint.

I have seen several Scrum projects where the work that was needed to bring Done user stories to production was far less transparent than the work that was performed in a sprint. Have you ever seen acceptance testers being frustrated because software was not integrated and deployed correctly? A good first step to improve such things is to introduce some transparancy: which steps are needed, what work is in progress, is there a bottleneck? Besides the Ready Kanban described by Serge Beaumont in an earlier blog, we introduced the Done Kanban.

If you combine this Kanban with the Scrum Taskboard and a Ready Kanban, the whole flow of user stories form idea to production is visualized. This enhances transparency of work that is done to user stories outside of a sprint. Below is a picture of a Scrum Taskboard that is combined with two Kanbans. The Ready Kanban shows user stories that are made Ready to be picked up in a sprint. The Done Kanban shows the flow of user stories from Done to production.

Below the Done Kanban is shown at a later point in time. By this time, it had really proven its value. In the project, user stories were integrated one-by-one with code that was made by non-Scrum teams with a longer release cycle. After introduction of the Done Kanban, this integration became a joined effort instead of a single person’s job. It also became more clear to everyone which user stories had been put into production.

To conclude, user stories often exist before they are Ready to be picked by a team in a Sprint. After they are Done they are often not yet in production. In combination with the Scrum Taskboard, Ready and Done Kanbans are a great way to visualize the complete flow of user stories form idea to production.

Jeff talked about the dramatic difference between those teams that take the red pill (that Morpheus offered Neo in the Matrix), and the blue pill that most people take. After his presentation, many attendees felt like they had just taken the red pill. I hope that this inspiration lasted long enough to have some effect at work, where countless small and big obstacles cause many people’s pill to be blue.

After dinner, which was accompanied by a nice Italian ice cream booth, we had a question and answer/discussion session in which Jeff touched many Scrum related topics. Usually at nlscrum events, we host an OpenSpace to give members of the nlscrum community a chance to share experiences. This time, we decided to opt for a different format to give a maximum of attendees the opportunity to learn from and get inspired by Jeff.

The topic that triggered most debate was a discussion about Kanban versus Scrum. According to Jeff, Lean principles and techniques are important to do Agile software development projects successfully. In fact, last month Jeff gave a Deep Lean course with Henrik Kniberg and the Poppendiecks. For those interested, you can find the course material online, including a presentation about Kanban versus Scrum by Henrik Kniberg.

All in all, I’m very glad by the way this special nlscum event turned out to be. We had approximately 65 attendees and got a lot of positive feedback. I hope to see many of them again on our OpenSpaces. So, for all of you in the Netherlands who use Scrum or plan to do so, come to our nlscrum events to get inspired and learn from your peers!

Photos: Laurens Bonnema

The most common way to estimate user stories on a product backlog is by doing a planning poker session. However, in my experience it is pretty hard for a team to do this effectively for a big list of user stories. Therefore I tried out another approach.

While going through a big list of user stories in a planning poker session, team members generally try to find out as much detail as possible about every user story. For each single user story, team members often don’t feel confident about making an estimate unless they have in depth knowledge. Because of this, focus is too much on being precise and not enough on being complete. Such estimation sessions need a lot of moderation to produce a fully estimated backlog in a reasonable amount of time. Also, while going through the list, it is hard to ensure that estimates are correct relative to each other. This requires to repetitively compare user stories with stories that have already been estimated while going though the list.

Recently, I have successfully tried another approach: Put every user story on it’s own piece of paper and let the team order them on a horizontal scale. This was done right after the product owner had given an overview of the user stories. This approach has two advantages:

• It makes more explicit that the estimation session is about estimating relative sizes.
• Team focus is more oriented to the whole list at the same time.

I was amazed by how quick an initial ordering was made. While this was in progress, some of the usual discussions about user stories took place and some splitting and grouping of user stories was done, but much more from a holistic point of view than with a sequential approach. To be sure that we all felt that the ordering was right, we still went sequentially through the user stories (low to high) after an initial ordering was made. This triggered some more discussions and improved the ordering, but for most stories consensus about its place on the scale was reached quickly.

Once the order was right, assigning story points to the user stories was a matter of drawing lines between groups of user stories on the scale. After that some quick triangulations were done to ensure that story point estimates were correct relative to each other.

Compared to planning poker, the main disadvantage of this approach is that it helps less in balancing different views of team members. Therefore, I think this approach is mostly preferable in situations where there are many stories to be estimated and/or when team members have no prior experience in estimating relative sizes.

#!/bin/bash

CLASSPATH_PAGE=FitNesseRoot/MyTests/content.txt
echo "!contents" > $CLASSPATH_PAGE
echo >> $CLASSPATH_PAGE

# First add the output folder of the fitnesse project to the classpath
echo "!path target/classes"  >> $CLASSPATH_PAGE

# Then add the output folders of the other projects
for i in `ls ../*/target/classes | grep "target/classes:" | tr ":" " "`
do
    echo "!path ${i}" >> $CLASSPATH_PAGE
done
echo >> $CLASSPATH_PAGE

# Then output the jars on the maven classpath
mvn dependency:build-classpath | grep -v INFO | grep -v Downloading \
    | tr ":" "\n" | sed "s/^/-path /" | sed "s/.*\.m2\/repository/!path \${MAVEN_REPO}/" \
    >> $CLASSPATH_PAGE

Before using it, please note the following:

• The script generates a page with classpath entries on a location specified by CLASSPATH_PAGE. You have to change the CLASSPATH_PAGE to your own page.
• The generated classpath assumes that Java system property MAVEN_REPO is set. This can be done by updating the FitNesse run.sh script to include -DMAVEN_REPO=`echo ~/.m2/repository/`.

I tried to translate it to a Windows script but ran into the problem that the Maven classpath was bigger than the Windows limitation of 8192 characters. If you find a solution for this (other than using Cygwin), please share it!

1 – We hire the best people using a rigorous technical assessment procedure.
Almost three years ago I chose to work for Xebia because of the enthusiastic, incredibly smart and skilled people that work there. This is still the biggest reason for my fondness of this company. Having worked closely with my Indian colleges has extended this experience in interesting ways. I am as much inspired and impressed by them as by my Dutch colleagues. Besides that, they take initiatives to organize very cool events like an Agile conference that I attended and a visit of Tom and Mary Poppendieck.

2 – Teams are distributed, on site and offshore team members jointly take the teams’ responsibility and work closely together as One Team.
We have chosen to structure our project teams so that each team contains Dutch and Indian team members. This works even better than I had expected when we started to work in this way. Doing daily stand-up meetings (with web cams), joined planning and retrospective meetings and having lots of intermediate interactions work great for team bonding across geographical boundaries. When I visit India or when Indian colleagues visit us, we feel like we already know each other pretty well, even if we meet in ‘real-life’ for the first time! I have asked several of my Indian colleagues to compare their One Team experience to earlier offshore experiences at other companies. Al of them liked the fact that there is no ‘us’ and ‘them’ feeling in this approach. We’re in this together and if we encounter some problems during a project, we all know the ins and outs of it and will not start to blame ‘the other side’.

3 – We share our software development and collaboration tools using one wiki, one code repository, one continuous build system, one mailing list etc.
I have learned that software development in a highly distributed way like we do can be done using mostly mainstream tools like Jira, Bamboo Confluence and Subversion. Also the tools that we use specific for communication are pretty basic: Skype, VNC, web cams, microphones, speakers, headsets. The only critical thing you need is a good internet connection on both sides. The biggest technical problem that we faced was that frequent power failures in India caused hiccups in our network connections. This got solved by the better use of UPSes. Some other problems were actually a lot of fun to address, like the way we manage to share obscure hardware.

4 – We work in short iterations.
On most of our projects we work in two week iterations. Before I started to work in two week iterations, I was afraid that this might be too short. I especially felt that the overhead of planning and retrospective meetings might become too big. Now that I’m used to two week iterations, I would not like to go back to longer iterations. The workload is evened out much better over time. In my past experiences, projects that had longer iterations usually had relaxed beginnings and stressed endings of iterations. It proved to be hard to get a team focused if work did not need to be finished within one or two weeks. It turns out that the disadvantage of the overhead of planing and retrospective meetings in two-week iterations is manageable, but it is important to take care that these meetings are done effectively and timely.

5 – On site and offshore team members are collocated during the initial 2-3 iterations of a project and there are frequent exchanges of team members between the two locations.
Even though I was surprised by the level of team binding that can occur if you only see each other on the other end of Skype session, some communication is more effective if you’re at the same location. Especially in the beginning of a project if you start off with a group of people that still needs to become a team, being at the same place helps a lot in helping the formation of One Team. It is also a lot of fun to get to know each other better while drinking beers (or cola) in a pub together. What makes you tick, how do you live, what did the place where you grew up look like? Besides having had a great time at the project I feel that I have also learned plenty of new things on a more personal level.