We have just finished with the Penn State University Project. This project was a way for me to evaluate the reverse sourcing phenomena and to make a difference to our education system by playing a demanding customer’s role for a University project. Overall I had a great experience doing this and the students really enjoyed working on this project. (I owe a separate blog to talk about the overall project, now that it is over). In this blog, I want to highlight something that I always felt about user stories but was not clearly able to articulate.

The Mystery of Shrinking Stories:

Over the last 5+ years of my experience with User Stories, I’ve seen people constantly trying to reduce the scope (size) of the user stories. (Jeff Patton has a really interesting blog about the same). Seeing this trend I’ve been frustrated a lot of time when my customer or team members don’t understand what is happening.

The problem was the stories were too granular that it was easy to miss the big picture.

Functional Areas :

To avoid this problem we started grouping the stories into functional areas. The Product Owner would identify the highest priority functional area and we used that functional area to identify our iteration/sprint stories. The developer would come up with a list of stories and tasks that fit under that functional area. (Mostly this would be done before the planning meeting). In the planning meeting we would have a collaborative session with the Product Owner to decide what stories need to go into the iteration/scrum based on the estimates. But we still had a big estimation session and then we would identify a list of stories. This clearly simplified our planning meeting, but

• The team members still did not have 100% clarity during the iteration/sprint on why certain stories made it and some did not.
• Both sides felt like there was a compromise in terms of the identifyed stories. The Product Owner might want some story but the developers would say its not possible because the estimate is high on it. The Developers might want to work on some story because it makes sense from a technical point of view, but the Product Owner did not prioritize that story.
• Also another problem we ran into was there were a lot of times when we wanted to pick stories from different functional areas. But in this approach we could pick up stories only from one functional area.

Using Themes instead of Functional Areas

We used different approaches to identify Themes.

1. First we started off with identifying a list of high priority stories and then tried to put a theme around it. This clearly did not work as well.
2. Some times we tried to identify a list of high priority functional stories and use a theme for the technical stories. This worked well when the technical debt was really high. For Example, Refactoring is a theme for this iteration/sprint.
3. Finally we asked the customer to identify a theme and the developers would then identify stories based on the theme. This was very similar to the functional areas except that now we could identify stories from different areas.

Again we had similar issues with previous approach.

Each Iteration/Sprint has a clear Goal

Finally we tried having a goal per iteration/sprint. The Product Owner would communicate the goal to the team; the theme would discuss about the goal with the PO and get their clarifications. After which the developers would come up with a list of stories that will help them achieve that goal. Sometimes they might only be able to achieve part of the goal, and then the goal will be updated accordingly.

This gave the business folks to clearly communicate what they wanted to see at the end of the iteration and also that fits into our release goal (each release had a clear goal, but before this we did not have a goal per iteration/sprint). For the developers this meant they could thin slice the stories accordingly to fit into the iterations. Suddenly developers moved from an estimation mindset to a budgeting mindset. Also from the PO’s perspective the story is really the goal, which is fairly high-level and the developers used user stories as tasks to keep track of progress and to split work amongst them. I was never a fan of tasks under the stories and this helped us get rid of them. Technically user stories (not really give by the user, written by the development team from user’s perspective) became our tasks and the goal became our user stories. This way we were able to make our stories quite large in scope (really, its one story per iteration/sprint). There is a similar concept in Scrum. They talk about Goals for a sprint, but there are multiple goals per sprint. In our case we had only one goal per sprint and we had stories under that.

What we did on the Penn State Project:

We started off with me (Customer or Product Owner) explaining them the overall vision of the project. So that, all of us has the same mental model. We used a mindmap for this. Next, I started of setting a goal for the iteration and also giving them a list of high priority stories (since they were new to the whole concept of stories). After a few iterations, I just gave them goals, asked them to email me the stories the next day and then in our bi-weekly demos, they would demonstrate each story and I would get to rate if they fulfilled the goal or not.

Some sample Goals are:

• Have at least one conference up and running
• Build versioning into the system ( This meant they had to add version each page, each artifact under the page, version templates, version the whole conference, there could be multiple conference under one site, so version all of them)
• Add template support (This means layout templates, Style sheet, include template, etc)

This has been my experience of moving away from Granular User Stories to Goals. I would love to hear your experience.

I just got back from Chandigarh after participating in the Agile Chandigarh 2008 workshop.

Vikram Dhiman did a great job of organizing the workshop. I really appreciate his initiative.

We had over 35 participants from 11 different companies. I was surprised by the level of Agile knowledge the participants had.
I ran the Waterfall to Agile demo followed by Agile Overview presentation. After this, Vikram gave a great presentation on Agile Myths. The last presentation of the day was from Rajesh. Rajesh spoke about the role of a manager. Rajesh was just introduced to Agile by Vikram a couple of weeks back. Rajesh has been doing Management consulting for the last 15+ year and he was happy to see that Agile is embracing what he calls “Common Sense” management.

Vikram will upload all the slides soon.

Thanks to all the participants and organizers. I wish more people take up initiatives like this, so that we can spread the agile awareness faster and move up the value chain.

Just noticed that the Agile Alliance Group that I has created in LinkedIn is growing massively. We have 1403 members so far. If you believe in Agile, join this group and show your support.

To join this group on LinkedIn click the following link: http://www.linkedin.com/e/gis/37631/0FF74232FB92 (You’ll need a LinkedIn Id. If you don’t have one you can always create one for free)

I hope joining this group will activate the consciousness of belonging to the Agile community as a network.

Why do companies spend enormous efforts in vain searching for “Best Practices”? Development Best Practices, Deployment Best Practices, Best Design Practices, Language Best Practices and so on….

I really feel uncomfortable when people talk about Best Practices. A lot of times we get stuck up in coming up with “best practices” as if they were final or ultimate. The whole point about Agile is, software development approaches are not static or final, we keep evolving and emerging. If something by nature is dynamic, evolving and emerging how can we say this is best? IMHO “best practices” exist only for a given context at a point in time (seconds). As soon as the time is over or the context has changed its no longer best.

Personally I prefer calling it “Better Practices”. For Ex: This practice in this context is better than the one we were using before this and hopefully tomorrow there will be a slight variation or a different practice which would be better than the one we are using today. There is no best, its only better.

When I was standing for the Agile Alliance board election in Aug 2007, in my position statement, I claimed that if I get on the board I want to “connect the dots”. I did not get on the board, but later when I got the Pask Award, I claimed again that, I really want to focus on “connecting the dots”. That would be my theme or vision for the next couple of years.

If you know me, you know that I’m really passionate about building a network of highly skilled, talented and passionate professionals. Personally I have experience the magic of working/collaborating with such folks. It is the knowledge and learning from these folks that has made me what I’m today.

In the Agile community, we have a lot of Agile practitioners who are doing great work. But they all seemed to be scattered all over the place like islands in an ocean. Trying to connect these islands [practitioners] can bring a lot of value in terms of knowledge sharing and identifying innovative idea and concepts. I think Agile Alliance is in great position to do this. So with the help of Agile Alliance I want to build a global community of these folks by bringing them closer and facilitating collaboration between them. Networking them is the first step towards this.

Hence recently I created a group for Agile Alliance on LinkedIn.

Purpose of the group: To connect Agile practitioners. If you are a supporter of Agile Alliance and Agile in general, please join this group.

Many professionals I know, have a linked in account today where they maintain their profile, resume, connections with other professionals, recommendations, etc on LinkedIn. IMHO, I am hoping that this existing informal network will provide a simple way for me to connect the dots and build a network of Agile practitioners who support Agile Alliance. Linkedin has another feature called “Recommendations” which is another way for the community to recommend and certify other practitioners to build a trusted network. Recommendations could be an alternative to “over the counter” certificates.

So if you would like to join this group on LinkedIn click the following link: http://www.linkedin.com/e/gis/37631/0FF74232FB92

I hope joining this group will activate the consciousness of belonging to the Agile community as a network.