Saturday, September 20, 2014

User Story Mapping Tool Review – SmartViewApp

I’ve tried to give consistent advice when people ask me what tools I would recommend for agile teams. In my opinion, the best tools to start with are sharpies, post-its, and retrospectives. With these basic tools, you can create story maps, track your improvements and progress with a kanban board, and build just about any report you need in Excel. For beginner teams and co-located teams, this is often more than enough. However, as you grow, start working with remote team members, or just want more advanced and automated reporting, you might start exploring the tool market.

As a big fan of user story maps, I’ve been on the lookout for ALM tools that include them and occasionally talk to tool vendors to see what their long term plans are regarding story maps. As you can read in the comments in the link above, the options are slowly increasing. In this post I’d like to highlight a new entry into the ALM market that combines both story mapping and kanban in a simple yet effective package.

In order to give this application a good test of its capabilities, I decided to try and create a story map that mimicked the example I created here.  I was able to easily create the map, prioritize the features into releases, set the status of the features using the kanban board, and generate a few metrics. Here are a few screenshots: 

This is a picture of the user story map. At the top of the page you can see the four user activities displayed as envelopes. In this view, the Manage Calendar activity is open. Similar to my original story map that I created in PowerPoint (yes, really…), the map allows you to display the releases (I’ve used colour coding), and the status of each feature (green check mark = done, etc.). Dragging features up or down or between user tasks is simple.

The kanban board mimics functionality you can find in most tools. It allows you to set your own columns, set wip limits, etc, and it gives you some metrics and reports like Cumulative Flow Diagrams. One nice bonus of this tool is that it is already available as an iPad app so that you can carry your kanban board and map with you anywhere.
IPad Version
Web Version
I was able to set this project up as a public project, so if you want to take a look for yourself, click here.  Note – this application is currently only available in ‘modern’ browsers, so you may need to download Chrome or FireFox.

Not only does this tool support two of my favourite agile practices, it is also simple and easy to use. That means you can continue to focus on the important things - “individuals and interactions over processes and tools”. Since the tool is currently in Beta, it also means that it is ready for your input. In fact, some of the changes I’ve suggested have already made it into the product. So, if you think your team is ready to add an ALM tool, check it out here.

P.S. Need another reason to try this out? It calls us “people”, not “resources”. Thanks SmartView!

Wednesday, March 26, 2014

Personal Kanban, velocity, and replenishing the ready queue

I was asked this question recently about personal kanban:
"For our project board, we pull stories into (iteration) WIP based on our planned velocity for an iteration, That is, if we plan to deliver 30 points we don’t go crazy and pull 100 points worth of stories into WIP. Of course, if we complete the 30 points we can pull more, but that is not relevant to this question."

"I’m wondering whether velocity is considered when managing a personal Kanban. That is, how can I limit what I pull into WIP, given points are not assigned to personal tasks and there are no planned iterations?"

"Any thoughts on this would be appreciated."
Great question. There seem to be two questions here. The first is "how many cards can I do in time period <x>", and the second "how many cards do I pull into WIP?"

1. How many cards can I do in time period <x>?

One of the benefits of doing personal kanban on a regular basis is that you start to find out that what you thought you might be able to complete in time period <x> usually tends to be unrealistic. Between disruptions and things taking longer than expected, you usually find out pretty quickly that you are completing less than you had hoped. That is also one of the advantages though - finding out how much you can realistically accomplish in a given day.

However, unlike 'traditional' agile, I’m not aware of a lot of people using points or velocity on their personal kanban board. In fact, even agile teams are starting to move away from points - especially those using kanban. There is no concept of points in kanban, but rather things like cycle time (how long a card takes to go from ‘ready’ to ‘done’) and throughput (how many cards you can complete in time period <x>).  Kanban assumes you are breaking things down into small-ish cards, and then based on the laws of averages (and the laws of bad estimating) that the number of cards you complete in a given time period (throughput) will even out over time so you don't need to estimate the number of points, but rather count the number of cards.

If you use personal kanban for a while, you can start to track how many cards you can do in a day and use that for your planning. Personally, I don't accurately know my personal  daily throughput because I'm too lazy to track it myself. But with trial and error, I've been getting better at understanding how many cards I can do in a day. I'm also using a 'Reflect' column (thanks Jabe Bloom for the tip) that gets filled daily with everything that I complete on that day. At the end of the day I take a look at everything I've done, the type of work, the value of the work, etc, and then move it to Done.

2. How many cards do I pull into WIP?

On my personal kanban board, I try to have only one card in my WIP. Less than 5% of the time I have to break that rule because I'm waiting on something and I don’t have the ability to unblock it. About 0.5% of the time I'll have 3 cards in my WIP because I'm waiting for 2 things. But generally, I only have one card in my WIP.

On a related note, I generally have 5-10 cards in my 'ready' queue and I spend time at the beginning of each day replenishing that column. If something comes up during the day I'll definitely add it in at that moment, but I find it helpful to organize and prioritize when I arrive at work, and before I dive in to the day. It helps give me some cognitive ease which allows me to focus more effectively when I start to go through my cards.

Hope this helps. If not, ask away!

P.S. For more on personal kanban, you can find the experts here: www.personalkanban.com or read Matt Heusser’s recent article “Yesterday’s weather”

Subscribe to Winnipeg Agilist by Email

Monday, September 30, 2013

Running a Positive Retrospective (and avoiding a gripe session)

A few times recently I've been asked about retrospectives - specifically how to keep them from becoming a gripe session. Here are a few things that I've found effective:

1. Start with the positive 

While we certainly want to talk about and address any issues, I like to talk about the positive things that have occurred during the last period before we delve into things we might want to change. I haven't yet been involved in a retrospective where the list of positive things wasn't long. This helps set the tone for the rest of the retrospective.

2. Wording matters 

I still have strong memories of watching Linda Rising run a retrospective for the Agile Vancouver organizing team in 2010. The words she chose as facilitator were powerful in keeping the retrospective positive yet useful. Instead of writing down "what went well", participants were asked to complete the phrase "it was great because..." (see the full quote and story at the link above). Instead of writing down "what didn't go well", they were reminded that no process is perfect and to write down "what they would do differently the next time". This simple re-wording of the phrases is powerful.

3. Every voice is heard 

If you've met me in person or even just through this blog, you probably know my passion for silent brainstorming. Generating in silence and discussing out loud isn't just a great way to get more ideas on the table, it is also a fantastic way to make sure every voice is heard. We've all been at retrospectives where one or more people with loud voices carry the conversation and the ideas. That isn't fun and doesn't encourage a positive atmosphere.

4. Build up Trust 

Using the 3 things above have shown themselves to be important in building up trust but sometimes you need to go a little farther. With new teams I've found that walking through Norm Kerth's prime directive can be a helpful way to eliminate blame from the discssion. They don't even have to believe the prime directive is true, they just have to act as if it is true for the period of the retrospective. I have found this pattern to be important to building up trust over time.

5. Do the (small) change

Finally, the point of all of this is to find ways to improve. If your team is having positive discussions about change and then doesn't follow through, the retrospectives become a waste of time. One simple way to make sure the change happens is to put the action items into your backlog and then start off the next retrospective by reviewing them to see if they were done and if they were helpful.

All the best in making your retrospectives more powerful by making them a positive experience. Feel free to add your tips in the comments.

Subscribe to Winnipeg Agilist by Email

Sunday, June 2, 2013

Don't Etch your User Story Map in Stone

I was having a chat with Adam Yuret last week about user story maps. A concern that he expressed and others have voiced is that by putting your ideas into a user story map it might discourage you from changing the map as you start delivering the stories and learn more information. He's right - it might and it probably does. Kent Beck recently expressed a similar concern about product roadmaps on twitter.

So, here is your reminder that your map isn't just a list of features, but is really a list of unvalidated ideas. Whether you are working on a startup or an enterprise project, you begin with a list of questions or assumptions. Here are some examples:
  • Will anyone use it?
  • Will anyone pay?
  • Does anyone care?
  • How will we make $?
  • Can we build it?
  • Do we understand the problem?
  • Will this solve the problem?
  • Will it perform adequately?
  • Will it integrate with other applications successfully?
  • Can we build this with the budget & schedule we have?
  • What is the best architecture for this project?

When you build and prioritize your map, you should be doing so with these questions in mind. As you resolve each of those questions, your map should change. It is one of the great reasons to put your map on the wall using post-it notes instead of putting the map into a tool - post-it notes are easy (and fun) to move. (Aside: Yes, there are sometimes excellent reasons to put things into a tool.)

Two quick stories to illustrate:

At a recent Agile Winnipeg event a local company (UnionWare) told a story of how they are using story maps. They had an idea for a project and quickly built a story map around that idea. At their customer conference they reviewed their ideas and realized they had missed the mark. They quickly (and easily) adjusted their map to confirm with their customers the new priorities and direction before they had even started building anything. The map itself was enough to help them walk through some of the questions above. As they told this story, their CEO recounted how he thought to himself: "This visualization stuff, it's going to be good."

For a project that I worked on this year we built a large map outlining all of the stories. We spent time going through the map with our customers slicing, scoping, prioritizing, identifying risks and assumptions, etc. We were pretty proud of the result and eagerly started delivering. As we started working on the first small release, we quickly realized that the answer to one of the main questions "Can we build this with the budget & schedule we have?" was "no". At this point, we had conversations with our users and sliced, scoped, and prioritized even more so that we could deliver something that would still meet the goals of our upcoming deadline.

In summary, "You cannot plan the future. Only presumptuous fools plan. The wise man steers." - Terry Pratchet. Don't etch your user story map in stone - build it with paper and expect to change it as you learn.



Sunday, May 12, 2013

Visualizing Retrospective Priorities

We tried a new retrospective prioritization/voting technique this week that worked really well. After we had generated and discussed all of our ideas for improvement, it was clear to me that there were several excellent ideas and it would be hard to use our regular voting technique to single out one or two. In fact, it seemed clear that there were several ideas that should all be done and were somewhat related. I decided to try a technique in order to visualize the priorities, grouping, and weighting of the ideas.

I drew a line on the whiteboard from the bottom right to the top left and put all the ideas we had generated in the middle of the board. I then asked the team to approach the board and move the items they believed would have the most impact to the top left and the least impact to the bottom right. Yes, I was a little worried about the priming effect of having everyone voting together but I decided to ignore my own advice this time.

After the post-it notes on the board 'settled into position', we held another brief discussion to confirm the position of the ideas. It was clear that there were several high impact ideas on the board that needed to be implemented right away and some interesting clusters formed at the top left. The position of the post-it notes also visibly identified the ideas that the team thought would have a lower impact and could be dealt with another time.
The final confirmation that this visualization of priorities was effective came later that day - the team met and started implementing their ideas.

P.S. Yet again the 'take it to the team' approach resulted in a better solution than the ones I had envisioned prior to the retrospective. #TeamGenius