It’s that time again – the New Year, when we look back at the past year and think about what we’d like to change in the coming year, much like retrospectives. This act of looking back happens much more frequently … Continue reading →

It’s that time again – the New Year, when we look back at the past year and think about what we’d like to change in the coming year, much like retrospectives.

This act of looking back happens much more
frequently on Agile projects, since the Team conducts a retrospective at the end of every iteration. The goal is the same though – to look back at what went well, what didn’t go so well, and what we’d like to change in the upcoming iteration.

Just as it is challenging to make meaningful New Year’s resolutions that you can actually stick with for any length of time, it can be a challenge to come out of the retrospective with well-defined, actionable items that can affect a real change in the upcoming iteration. For example, a Team that is having trouble meshing as a group might focus on the problem in a retrospective, but not come up with a concrete way to address it. “We will communicate better” or “ we will have more trust in each other” are good goals, but not concrete enough to actually change behavior, especially in the space of a short iteration.

An example of a more concrete goal might be that the team agrees to have lunch with each other 3 times a week. Breaking bread together is a powerful act, and would also give the Team members a chance to get to know each other outside of their working relationship.

I talked with a team recently that was not good at estimating, so they decided to give it up! Having planning sessions every iteration provides a great opportunity to get better at planning and estimating. Suppose one of the problems identified in a retrospective was that the Team under-estimated the amount of time needed to develop a user story. If they are tracking their tasks daily, and keeping their task estimates updated, they can analyze that data in the retrospective and see what aspects of the story took longer than expected.

The outcome of the analysis could be one of many things – the story wasn’t “ready” to work on, testing or some other activity took longer than expected, etc. Rather than giving up on estimating, the Team could use the results of the analysis in the retrospective to come up with concrete changes to try in the next iteration – for example, having more information about the story before planning, or adding more time to the testing tasks for each story. At the end of the new iteration, they could see if the changes made their estimates more accurate. Even if the changes didn’t help much, they would have learned something!

Retrospectives help teams learn together, but only if the Team develops concrete ways to apply that learning to the way they work together. New Year’s resolutions are similar – if they are too vague (“I’ll work out more”), they are difficult to stick to! So Happy New Year, and here’s to applying what we’ve learned in the past to make this year a great one! And if you are looking for ways to run more effective retrospectives, I highly recommend Agile Retrospectives: Making Good Teams Great by Esther Derby and Diana Larson.

“Ready” is a Scrum concept that applies to making sure that the Team has enough information about user stories to be able to implement them in an upcoming sprint. Roman Pilcher says that a “ready” story should be clear, feasible, … Continue reading →

“Ready” is a Scrum concept that applies to making sure that the Team has enough information about user stories to be able to implement them in an upcoming sprint.

Roman Pilcher says that a “ready” story should be clear, feasible, and testable. I’m fond of analogies, and I think the concept of ready also applies to cooking. Suppose you are getting “ready” to cook a new recipe for dinner – what do you need to do? Basically, you need to read the recipe, and assemble the ingredients.

Ingredients

What ingredients might you need to make your stories “ready” to cook up in the next sprint? Some ingredients might include:

– Domain knowledge: Do you need to get information from the users or other stakeholders before the story can be implemented?

– Narrative: Is this story part of a larger narrative? Most stories are, and narratives can provide context for an individual story.

– Acceptance criteria – How will you know when the story is done? How should the story behave? Acceptance criteria provide the basis for testing the story.

– User interface mockups – A picture is worth a thousand words, so creating a quick mock-up allows the Product Owner and the Development Team to have a clearer picture of what the interface should look like, and usually also helps define clear acceptance criteria.

– Data definitions – Is there data associated with the story? If there is, what are the data elements, and what are their attributes? Any default values? Should input data be validated? Many agile teams use a data dictionary to capture this type of information, which is wise since most data elements are used in multiple stories, and the data dictionary makes it easy to capture and maintain that information in just one place.

– Qualities (AKA non-functional requirements) – What qualities does the story need to have? Are their security or privacy concerns for data that is being captured? What about performance? Usability?

Suppose we were about to “cook up” this story:

As a sailboat renter, I can see a list of boats in a selected location so that I can see what boats are available there.

What ingredients do we need to have in order to be ready to cook?

– User interface details: What should the list look like? What order should it be in? (Domain knowledge might help with this question – should catamarans and mono-hulls be listed separately?) Should the list be sortable? If so, how should the user be able to sort it? You could capture some of this information in a simple mock-up, and some of it in acceptance criteria.

– Narrative: This story is part of narrative in which a prospective renter is searching for a boat to rent. When they select a boat, what should happen next? That will most likely be a different user story, since this story is about displaying the list of boats, not about selecting one. You often discover additional stories during this process. But knowing that the user will need to be able to select a boat to get more information about it also helps the team see the context in which the story will fit.

– Data definitions: What should each boat description contain? Should it have a snapshot of the boat? What other information should be displayed? When the user hovers over a boat, should more information be displayed? Do we already have a data dictionary description for a boat and its attributes? Do we need to modify it for this story?

– Qualities: Are there any qualities that apply to this story? From a usability standpoint, what if the list of boats is really long? What kind of scrolling should we provide? How should we indicate that there are more boats in the list?

If you are more familiar with the waterfall than the agile approach, this probably sounds a lot like detailed requirements analysis. There is a big difference though – in the agile approach you do this type of analysis on a just-in-time basis, in the context of what you have already learned and what you have already developed, rather than trying to figure it all out up front.

Spending some time defining what ‘ready” means for your team – The Definition of Ready – will help your team know what ingredients you need in order to cook up a great product increment in the next sprint.

I think people like a good fight. Certainly the media seems to, not only in the world of politics, but also in the worlds of sports and entertainment to name a few. In the world of business analysis, the current fight … Continue reading →

I think people like a good fight. Certainly the media seems to, not only in the world of politics, but also in the worlds of sports and entertainment to name a few. In the world of business analysis, the current fight seems to pit Agile methods against the Waterfall approach. For the next several blogs we’ll have a Scrum vs. Waterfall match. In corner #1, representing the Agile methods, we have the Scrum framework. In corner #2, representing Waterfall, we have the “traditionalists.”

Round One

Relative sizing of user stories (Scrum)

T-Shirt Sizes. For release planning we might use estimates of relative size. When less is known about the user stories for a release, we can estimate using a broad brush approach. Based on such criteria as how complex we think the user story is, how much effort it will take, and the unknowns or doubt, we give it a T-shirt size (XS, S, M, L, XL). We can then compare all the user stories and assign relative sizes. For example, we can take one user story and based on the above criteria assign it a T-shirt size of “Large.” We can then compare all the other stories against this “Large” size and assign the relative value of each story. This relative size estimating can help the Product Owner decide which user stories to prioritize for a release.

Story points. We can then assign each T-shirt size story points based on an arbitrary scale, such as the Fibonacci number sequence (1,2,3,5,8,13,21…). If a user story is Medium, for example, we might assign 8 story points. If Large, 13. We can then translate the T-shirt size of all the user stories into story points. It’s important to remember that these story points are still relative. It really doesn’t matter if a Small is 2 or 3 points, as long as it’s consistently applied.

Waterfall relative sizing of projects, phases, deliverables, tasks.

For years we have used use relative size estimates on traditional projects. I have found this most effective when actuals have been collected over enough time to have confidence in the numbers. While I have only used relative sizing on projects and deliverables (such as a small, medium, or large report), I know of teams that have used them on phases and tasks as well. As with Scrum, we usually base traditional relative sizes on complexity, effort, and doubt (risk).

Round 1—Scrum wins, but it’s not a knock-out.

In my experience using relative sizes on traditional projects is often done to short-change the planning process. With Scrum the relative size of the user story actually gets refined as it approaches the sprint in which it gets delivered. While some traditional teams have the discipline to refine the estimates (as a project manager I always encouraged it), many more give in to management’s pushback about not changing the date, scope, or cost. Scrum processes, by their nature, encourage change and refinement; traditional processes do not.

Round Two

Scrum Planning Using Delphi (Planning Poker®)

Planning Poker uses a kind of Delphi technique to reach consensus on the relative size of the user stories. Each person on the delivery team (not the Product Owner) is given a deck of cards, each card with a number. For example, if using the Fibonacci scale, the deck would have cards, each containing a number in the scale (1,2,3,5,8,13,21, etc.) going as high as desired. The Product Owner explains the details of the user story and at the count of three team members turn over the card with the points they think most appropriate. For example, two team members have turned over a 3, one a 5, two an eight, and one a 21. They discuss their reasons for “playing” their cards. Then at the count of three they turn over a card, the same or different from last time. Again, they explain their rationale. This process continues until consensus is reached.

Traditional projects using Delphi,

The Delphi technique involves a group of experts providing their estimates anonymously. Like Planning Poker, there are rounds. Although this can be done electronically, the experts usually write their estimates on a piece of paper. A neutral party takes the estimates, shuffles them, and reveals them to everyone at the same time. No discussion is supposed to occur. For the next round and based on seeing the estimates of the others, each expert provides a written estimate which can be the same or different from the previous round. The process continues until consensus is reached.

On traditional projects I have tried using Delphi anonymously only once. It didn’t work. I have found the power of Delphi is in the discussion of each person’s assumptions about the estimates.

Round 2—Scrum wins, but again it’s not a knock-out. I love the Delphi technique. I love having the team reach consensus on estimates, whether traditionally or through Planning Poker. It provides team accountability for the estimate, and increases the chance of team and individual commitment rather than compliance. So what difference does it make whether traditional Delphi or planning poker is used? Everyone can understand Planning Poker. I have seen teams take to this technique immediately. But while Scrum makes things easy and practical, the traditional Delphi feels arcane. In addition, the traditional approach has some points taken off for having to use experts and for the required anonymity.

So, the current score is two zip. But the match is not over. Much more to come…