Archives for August 2013

We started a new sprint last Tuesday. And we had our first stand-up of the sprint the following day. It didn’t go as well as I would have liked (we have three developers and one doc/testing person on the team; we then have 2-3 managers, a scrum master, a product owner and a agile coach all in the room). The meeting, and the going around the room with all of the people, was taking a long time, and non-developers were causing us to lose focus from the sprint goals. People were focused on what they were doing, rather than the team goals. The meeting had become one of “tell us what you’re doing” and not necessarily making progress. It had taken on aspects of what I call the “tell us what you did on your summer vacation” sharing at meetings.

I realized the problem when we had our stand-up two days before the close of the sprint. Everyone in the room did their three sprint questions, and we were about to adjourn. I innocently asked “What is your confidence that we’ll make the sprint commitment next week, and that there isn’t anything blocking the completion of those stories?” That sparked five minutes of fervent discussion, with people taking responsibility for the various bits needed to get to completion. But it does show that the daily scrum was not as focused as it could have been. I’d read posts like Mike Cohn’s “A weighty matter for the daily scrum,” but don’t think we’re ready for that yet.

There was also a thread that the stand-up was for reporting progress to the project manager. We made clear that this is for team facilitation, not for management. The three of us on the process decided to make a few changes, which will be refined over time. [The only management thing that we need is for everyone to update their remaining time on their tasks before the stand-up.]

• The three sprint questions and the sprint goal will be visible in the room. And these will be the “new” questions (see below). Hopefully on 11×17 paper in large print.
• People are on time, and we expect people to be present electronically if not physically.
• The scrum master opens the meeting with the burndown chart and any general observations.
• The only people who are in the round-the-room are the developers.
• The first developer is a person who is working on the current top incomplete story, as the focus is to finish the prioritized stories. Anyone in the room can join the discussion around that developer’s topics, as needed. But the general rule for non-developers is to only speak if you have a significant contribution to the topic. Keep the focus on the sprint goal. After the top priority, we go around the room to developers in whichever clockwise view works for the day.
• If a developer has been distracted or is working on other projects, they bring this up to the team. At a minimum, the team should determine if that person’s effort is needed to complete the sprint goals, and possibly have the scrum master go out to people outside the team to get that person’s attention back on the sprint goals instead of what they have been directed to.
• After all the developers have gone, the product owner, if present, may bring up anything.
• The scrum master then adjourns the scrum.
• If any stories were thought to be closed, the product owner might close them then, or schedule a future meeting with the right folks to review the story.

For reference, the “old” three questions for a daily scrum:

• What did you do yesterday?
• What will you do today?
• Are there any impediments in your way?

The three questions, as stated in the new Scrum Guide:

• What did I do yesterday that helped the Development Team meet the Sprint Goal?
• What will I do today to help the Development Team meet the Sprint Goal?
• Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?

What’s different? I didn’t appreciate this when I heard Jeff Sutherland a few months ago. But I am appreciating it more now.  First, it puts the focus on the team and not the person. That’s subtle, since the team is comprised of individuals. But the larger shift is that it focused the team on meeting the sprint goal. It’s not just that work has been done, but that progress is being made towards the overall goal. We started this focus in this sprint and, after a few days, it seems to be working.  Our daily scrum should be more focused, shorter and more productive in the future.

I’m liking the shorter, focused stand-ups. Any meeting that accomplishes its tasks and ends early is good in my book.

P.S. In our first daily scrum with these rules, we noticed that we had two stories with all of the tasks complete. What was odd was that a card marked as done (in the done lane) was also marked as blocked: the code needed to be rolled onto the production server, and that was an acceptance criteria. The story wasn’t done. There should have been another task, or the task moved back to an earlier stage before done. We elected to push it back a lane, but it was my first experience of the difference between done and done-done. That’s a topic for a future post.

I wrote a post earlier this week about working with a new scrum master. As I read Essential Scrum and prepared for my trip to Chicago to meet face to face on process, and our end of sprint and next sprint planning, I realized that the situation was a bit different than I’d thought.  I was in a new role. Here are the people and roles who are doing this for the first time.

• Scrum master – has a strong background in project management, but not necessarily scrum facilitation
• Product owner – the first product manager in the role in 6-8 years. While familiar with agile, has never been in a team
• Scrum/agile coach (that’s me) – In my first turn with scrum, I managed product owners and would drop into meetings. I was a regular in sprint reviews, (at the scrum of scrum level for the project) and team sprint reviews when it was a product and feature area of interest. I was a chicken, not a pig. Then I learned to train agile to product managers and took a five month assignment as product manager/owner for a Windows software product. That was an education (with a great scrum master) and I was a pig. I advanced past that to coach the two people above and adapt agile culture to the current situation.

The roles are now clear. And it is also clear that we’re all learning on the job.

I’ve now realized what this series of posts are in this blog. This is not as much about agile excellence or best practice. It’s the story of a great, committed, agile team learning new techniques on the journey to being more efficient and predictable, with three people new to the roles.

We did a number of backlog grooming sessions in the past week, as we put our focus on the deliverables needed before our 1.0 release comes out, coincident with a major international tradeshow where we will be exhibiting. We went into our sprint planning with a clear view of the backlog to make a viable 1.0 release.

We tried a few new things in this sprint planning, which made for a long afternoon. First, we did estimates in story points for all of the items that we wanted to include in this release. That spanned the time period of three sprints, and we have 2.5 sprints until the tradeshow. We’re close, and may actually make it if we keep focus and our velocity picks up as much as it has in the last sprint. One new thing that we introduced in this sprint was estimating in story points (not just t-shirt size) and planning poker cards with the Fibonacci sequence. The sizes felt larger than the effort expected and the stories too large (most were 13 or 20), but the team did take a consistent view of story size that led to these larger sizes. Rather than debating sizes, we went for consistency and figured that we’d see how it worked in the burndown. [Hint… our current trajectory shows us at 0 about 2/3 though the two weeks, but it’s still early.]

One of the items we noticed from the last sprint, where we did task breakdown by hours, is that tasks became dissociated from the stories… the task to-do became an undifferentiated pool of tasks. In the retrospective, we decided to do a few things:

• Change the focus to finishing a few stories first, rather than working on [potentially] all stories at once.
• Have the association of stories and tasks be clear.  So, if a story had the label “(A) Change the bulb,” the tasks were “A.1, acquire a new bulb,” “A.2 Unscrew old bulb and dispose,” “A.3  Screw in new bulb.” That ordered the task backlog well.
• Change from closing all stories in the sprint review to closing them mid-sprint, as completed.

We also made an attempt at writing a sprint goal so that the team could rally around the focus for the sprint. We left the room before this was complete, and went into the standup meeting to wordsmith this. In the future, the product owner should enter the sprint planning with a draft of the goal, and then it can be altered as the team commitment is refined.

As we start our sprint planning and backlog grooming and sizing in a few days, it seemed reasonable to point out a few more posts that others have written about their experience.

The best was “The Five Stages of User Story Sizing.” It outlines the stages that a group goes through in the process of agreeing on the point count for a story. The stages are:

1. Individual perspective: Everyone has their idea and needs to speak up.
2. Individual understanding: As people give their views, people begin to understand the full impact of the story.
3. Relativity: This is the key for me. The goal is not to design a story, but to compare this story with other stories of the past (whether individual or group) to find something comparable.
4. Group alignment: Through planning poker (Dzone),(MountainGoat) or fist of five, the group aligns around the size of the story.
5. Group wisdom: At the end of the planning session, people leave with a shared understanding.

And his encouraging words at the end are “Eventually, the team will get to a place where more stories start falling in the “We’ve done this before” category. User story sizing becomes easier and is a much more efficient activity as group wisdom and group experience expands.”

Another Dzone post, titled “What is the Right Size For a User Story?” gives a great view of the story sizing and the breakdown of a story to tasks.

Another blog post, titled “The mystery of the shrinking story” extols the value of the smaller story, but with the awareness that you need to adapt your process to have some upfront design before the story is started.  I’ve seen this done with research stories in a sprint before it’s expected that work would begin on a story, or often an epic. See the section titled “there’s benefit in keeping user stories small.”

Finally, there is a long slide deck available, from a product owner’s perspective, of the story definition and sizing process. Talk a look at it at Scrum Alliance.

Let’s go into Tuesday’s sizing of the next two sprints backlog and task breakdown on our next sprint with the knowledge of the process. It’s going to be a fun afternoon.

I’ve always been a product owner, not a scrum master or developer in a team. And I’ve had the pleasure to work with strong experienced scrum masters; I didn’t realize how easy my life was. Now I’m working with a new team and a new scrum master; after a bit of shock, I realized that this is a great learning opportunity for me to understand the role of the scrum master much better.

This post will have more text in it that describes the high points of each of these articles and my thoughts.  But, for now, I’m just doing the links.

Mountain Goat describes the role of the Scrum Master

Three Tips for New Scrum Masters

Leader of the Band: Six Attributes of the Good Scrum Master

It’s important for a sprint to be predictable. As stated in earlier posts on new teams, there is the issue of how to create good estimates, and a focus on completion. But one of the problems is how to deal with bugs and those critical fires, especially if the organization prides itself on customer support and responsiveness.  I’d like to give a few basic principles.

• Nothing gets done unless it is a task in the sprint and shows up in the burndown
• For a task to be added, it has to meet one of the following criteria:
  1. It’s a task that was not anticipated for an existing story, and would be added to that story.
  2. It’s something truly new: there should be a new story and a new task under that story.
• All changes in scope (new stories) are under the control of the product owner.

Simply stated, no task gets added to the work to be done in the sprint without it being associated with a story. If it’s an increase in the scope of the sprint, the product manager has to decide this and the team must accept the change in scope in the sprint.  Of course, we can anticipate a certain amount of these and have a budget for bugs and pressing. But we can also decide to just put this bug in the backlog for the next sprint. My view is that you’d be surprised at the number of things that can wait two weeks if you can tell someone that you definitely will look at it then. Most people want immediate responses because it’s easier to ask for that than it is to have to follow up when you don’t have faith that the other part will execute without your badgering.

The key is that every change is a deliberate decision. The product owner decides to change the scope of the sprint. And the scrum team decides to take it on. Or the scrum team decided that the size of the existing story was larger than expected, based on improved knowledge.

There are numerous articles and charts on how to deal with this:

• One way to handle Bugs and Production Support in Scrum
• Handling scope changes mid-sprint
• On changing requirements mid-sprint

My preference is to never change the scope in a sprint. But, as we have to make changes, let’s be deliberate.

And my preference is that if something gets to step 8 and tasks are added, you should be creating a story to go with it so that you can have a predictable velocity. And avoid these interruptions as much as possible.

I made a mistake earlier this week. I was in a product owner team meeting and the question came up “what is the goal of our current sprint?”  Nobody knew. Not the developers, not engineering management, not the product owner, not the scrum master. So I put the product owner/manager on the spot, and we all fumbled around for a minute or two, and we did eventually derive a clear goal for the sprint. I knew that something was wrong.

I’ve been reading the Scrum Guide on a daily basis now. Whether this is a highlight of life or a sorry statement isn’t clear, but it’s at least very educational. The section on sprint planning had this statement on the sprint goal.

After the Development Team forecasts the Product Backlog items it will deliver in the Sprint, the Scrum Team crafts a Sprint Goal. The Sprint Goal is an objective that will be met within the Sprint through the implementation of the Product Backlog, and it provides guidance to the Development Team on why it is building the Increment.

My mistake was holding the product owner responsible for stating the sprint goal. I should have held the full team accountable for this. That doesn’t let the product owner off the hook… it just adds everyone else.

It is important to come out of the sprint planning with a committed set stories and a sprint goal. The team will craft the sprint goal in our next sprint planning meeting.

I have a few concrete suggestions:

• The board that has the sprint burndown should have the sprint goal written on it as well.
• When we do the standup, the sprint goal should be displayed on the screen along with the burndown chart, since the standup is not where the whiteboard is.

I’ll write a better thing on this with my views, but here is my outline. It’ll get better later, but I’m being agile in my posts about agile.

Here’s a link to stories and story maps. It’s worth a read, as it expressed many of the concepts that I have used as a product manager.

Here’s the summary of how I like to think about it.

• The product owner is responsible for determining the major items for future development (I call them use cases myself, but they’re epics in agile). The personas, problem and value statement.
• The backlog should be organized by epics (the story map concept above comes close to this when it talks about the skeleton).  Only when an epic is brought into play do the specific stories show up.  But each of these stories would be tied back to the epic, so we all remember why we’re doing this specific story. Often, the development team creates these stories, as they understand the technology better.  But the product manager/owner is involved in the process and is the sole owner of the process.
• The backlog, rather than being one continuous list, is made of these epics.  Only the current sprint and the next sprint have stories plucked from their epics and placed into the team backlog. I’d call it a “lumpy” backlog, or a backlog of boulders, gravel and sand.

Also, you run into the issue of “who creates the user stories… is it the product owner, architect or the development?” Anyone can create a user story. The product owner can. The architect can. The development team can, either with their best understanding or when a story is split.

The Scrum guide says this pretty clearly.

“The Product Owner is the sole person responsible for managing the Product Backlog. Product Backlog management includes

• Clearly expressing Product Backlog items
• Ordering the items in the Product Backlog to best achieve goals and missions
• Optimizing the value of the work the Development Team performs
• Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next
• Ensuring the Development Team understands items in the Product Backlog to the level needed

The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable.”

I’m working with a great team that has been “sort of” agile for a while. They work well together. Many of the artifacts of Scrum were present (standup, sprint planning, close of sprint demos and retrospectives). Others were missing: a defined scrum master and product owner. Basically, we have a new scrum team.

Mike’s blog post on “getting predictable” speaks to this well. In fact, there are two parts of his content that rang true to me.

First he describes the difference between an agile project and total chaos.

Without the ability to make and meet commitments, without the ability to look ahead and forecast what might be able to get done… we are asking our customers, our businesses, to make an indefinite investment in a project with no general ideal of what they are going to get when time and money runs out. To me… that is total non-starter.

That speaks for itself.

He then goes on to explain the need to form a team and deal with the risk and uncertainty in the project early, rather than going for easy wins. This is something for the whole team to work on, so I suggest that you just read Mike’s blog on this.

I also recommend reading the LeadingAgile posts on sprint planning.

• Your Team Is New To Scrum
• Simple Cheat Sheet to Sprint Planning Meeting

A developer recently explained to me that “agile means that we plan this sprint and know our backlog; whenever we get enough done on the backlog for it to be interesting, we release it, but we don’t ever plan more than the current sprint.”  I didn’t choose to engage in an argument at the time; I just wanted to see his position.  In my own work, I observed that the team was not achieving the definition of “done” on half of the stories in the two-week sprint.  More interestingly, there was not even a common understanding of the goal of the sprint or the user value that would be achieved.

As we started having discussions about this, I realized that there were a few things missing:

• We had a very loose concept of a release plan, and the set of features (let’s call them epics) that would make up a useful release in the market.
• We had no estimates, and therefore no shared understanding, for the backlog. As we groomed the backlog to focus on only the interesting items for this release, the product owner team came to a realization that we didn’t have a shared understanding of the backlog items, and were uncovering this shared understanding during the sprint. I think I may have said “one of the cores of scrum is for the team to have a shared understanding of the requirement and the solution.”

Next week we’re going to do an estimating process, first for our next sprint which is just starting, and then for enough of a backlog for the next sprint. (We have a tradeshow coming up soon, so we have two sprints to deliver demonstrable value.) It’s not optimal timing within the sprint, but should get us to focus on our company objectives and have a shared understanding of what we can deliver.

Mike, at LeadingAgile, wrote a great post about estimating, titled “the real reason that we estimate.” I’d like to bring over a few paragraphs of his and then reflect a bit.

You see… estimating isn’t about estimating at all. Estimating is about creating a shared understanding of the requirements, and a shared understanding of the solution. When teams have problems estimating, its almost never an estimating problem, it’s a shared understanding problem. If you can get to the bottom of your shared understanding problem, you will fix your estimation problem.

The product owner needs to represent the problem well. The product owner team, a great concept of Mike’s, will work together to make appropriately bite-size stories for the backlog. The team will then estimate those. I’ll give my thoughts on product owners, product owner teams, who can create a story, and who is responsible for the backlog in the future.

Giving up estimating is basically giving up being able to give the business any idea of what they are going to get or when they are going to get it… even at a high level. My take is that we can’t give up estimating, we need to get better at estimating, but that means that we need to get better at creating shared understanding. It’s my opinion that creating shared understanding is the main reason we estimate. It’s not so much the number that matters… it’s the shared understanding that matters. If we are estimating without creating shared understanding, we are missing out on the value, and the estimates will always be poor.

One of the biggest things we need is some way to estimate size for epics (and stories as they get closer) and the business value of the epics. Then do release planning to determine roughly what will fit in, and refine as we go. But we’re doing this with some idea of capacity and time frame.