Tag Archives: Scrum

Scrum Tip: How to make planning go smoother

Posted on by

Sprint planning can be one of the longest, most painful parts of the Scrum process. I have been in planning meetings that take a full day and still end with many questions up in the air. It is terrible. But it doesn’t have to be.

Planning meetings have a singular purpose in my opinion: to define what the team is working on for the next sprint. Everything else is tangential. This is the real goal for me as product owner and development manager. Where does this information come from? The product backlog.

Having a well defined product backlog with good user stories can make or break a planning session. All the other planning details your scrum-master might have aren’t nearly as important as a good product backlog.

Define stories, don’t create them. If your planning meetings involve stakeholders continually modifying the product backlog during the planning, the product owner has failed. The stakeholders are there to help define the details of the story, not create new ones.

Have the right priorities. Nothing is worse than attending a sprint planning where priorities have changed since the last time the backlog was updated. Priorities and the backlog need to be updated continually so a sprint planning works with the latest, and most valid information.

Define stories just enough before planning. The product owner shouldn’t spend hours creating requirements documents. Instead, the team should just have a conversation regarding what the details of the story really are during planning. On the flip side, they must be defined well enough for the team to ask questions. Make notes better is a terrible backlog item because it has no clear goal.

I have been guilty of violating all of the above tips, but these are just a few of the things I have learned that help make product backlogs more useful and make sprint planing meetings go smoother.

Scrum Tip: Tools change with team dynamics

Posted on by

My teams have been practicing Scrum for nearly a year, and it has been an eye opening experience. I have learned a lot, as has everyone at Mailtrust. I hope to post a few Scrum tips every now and again to help others learn from our mistakes and experiences.

The first tip is don’t pick one tool for all your teams. Picking one shiny tool seems like the route to go when you first start Scrumming (that feels like a dirty word), but it isn’t. The Agile manifesto states something very important about how teams should be managed, and it says it for a reason.

Individuals and interactions over processes and tools

Team dynamics should influence the tools used during the Scrum process, not management or the company or anything else.

We have been through a few major iterations of tools, and here is what we have seen.

First Attempt – Excel

Excel was the obvious first choice we made for managing Scrum projects. The problem is, it is very hard to collaborate. This was a huge draw back that everyone hated. We quickly looked for other options.

Second Attempt – Google Docs

Google Docs took the power of Excel and made it collaborative. Pretty awesome. Many teams loved this approach. It was easy to have burndown charts, calculate availablility, etc.

The teams it didn’t work for were the larger teams. These larger teams needed much more flexibility than Google Docs had to offer. The fact is, Google Docs is pretty cumbersome when you have to make a lot of changes. Large teams are large for a reason. They have a lot going on. Lots of bugs come in. Lots of tasks are getting worked on. Lots of impediments occur. Lots of notes need to be taken on tasks. Lots of tweaks to the process need to happen each sprint. These teams needed something better.

My smaller teams took the exit ramp at Google Docs. They are still using it and it is working great. They don’t have as many changes or bugs coming in, so Google Docs isn’t as cumbersome. These teams are usually backend teams where priorities are much less volatile.

Third Attempt – The Board

The larger teams needed ultimate flexibility. Managing dependencies, priorities, and status of tasks and stories needed to be easier. So we went backwards in time, to the days before computers. To pencil and paper.

It has worked great for larger teams. At first, I didn’t think it would but pencil, paper, and a wall are so free-form, the team can develop the process that works best for them. That’s exactly why the larger teams are loving the wall. Here are some different things teams are doing with the board.

  • Different color post it to signify things like dependencies and test failures
  • Organize bugs at the top of the board. This is great for managers like me to see whether a team is getting killed with bug reports.
  • Limit the number of stories available to be worked on. This helps prevent teams from getting 90% of each story done instead of 90% of the total stories.
  • Limit the number of tasks in each status, like working, review, and testing. This forces team members to move tasks through the process and not leave them hanging around

board

Next Attempt – ?

If you haven’t noticed, the teams have been iterating, not just on the product, but on the process over the past year. This is at the heart of making Scrum successful for you teams. Each team will adapt and change the process to their needs, which is fine with me. As long as they continue to operate effectively, they are free to use whatever tool they need.

What makes a good product owner?

Posted on by

I read an awesome post on Coding Horror entitled Are you an Expert. There is a great quote that really exemplifies what product ownership means.

Being an expert isn’t telling other people what you know. It’s understanding what questions to ask, and flexibly applying your knowledge to the specific situation at hand. Being an expert means providing sensible, highly contextual direction.

A product owner has to be so in touch with the product, that they can ask the right questions. If the right questions aren’t asked, a team will soon be working on tasks that were simply on the list, not tasks that are important.

Trickery to utilize user stories

Posted on by

I hate the term user story. Not because I hate user stories, but because people usually look at you funny when you ask them for it.

If this happens to you, instead of asking for user stories, ask who this is feature is for, what the feature really means, and why its important. Now you have successfully figured out the user story, without having to tell the requester to start their sentence with As a.

These pieces of information are super important in prioritization. In a month, if you don’t know why something is important because you forgot, well you can’t prioritize can you?

Prioritizing the product backlog

Posted on by

The product backlog is one of the hardest parts of using an Agile process in my opinion. It quickly becomes a daunting list of tasks that can be unmanageable. What I hate most is the subjectivity of picking what items should be worked on. How do you really weigh what it is important and what isn’t?

Mike Cohn gave a sweet presentation on just this topic. Listen up for Kano analysis, which I think is the simplest and probably most powerful way to weigh new features.