Great Teams Satisfy Everyone’s Priority Needs

As a software development blogger, I often write about ways for teams to adopt agile practices or be more agile. There is no single way to be agile. There are many. There is no best way to be agile. There are multiple. What can your team do?

Ultimately, software development teams must establish rules and procedures that work for them. They have to be able to embrace the development process and make it their own. If they can’t do that, they won’t succeed.

Here’s a true story about revising a business process.

Recently, I was involved in a series of meetings where we reviewed an established business process and discussed ways to improve it. There’s always room for improvement, right? There certainly was in this case.

It quickly became apparent that there was a fundamental problem. The business stakeholders and the process implementors were in conflict. They had different priorities and interests.

The highest priority for the stakeholders was maximizing revenue. The highest priority for the process implementors was customer care. I could argue that you can’t have one without the other but that should be obvious. Two things became crystal clear:

1. If the financial objectives of the stakeholders couldn’t be met, the business initiative would be cancelled and the process implementors would be out of work.
2. If the implementors couldn’t provide the level of customer care that they were committed to, discontent would prevail and employee turnover would be high.

What’s the solution? The needs of both the stakeholders AND the implementors MUST be satisfied — whatever it takes. Thankfully, I was able to offer a solution that appealed to everyone.

Focusing on what people need makes a difference.

The same type of problem occurs in software development teams. Management wants the software delivered in less time, with better quality, at lower cost — no surprises there. The software developers want to solve problems, write good software, and avoid administrative impediments — no surprises there either.

Management needs the development process to be controlled and transparent. The team needs the development process to be lightweight and non-intrusive. The needs of both sides MUST be met and they CAN be met if everyone is willing to negotiate and compromise.

Conversely, if the needs of either side aren’t met, quality will suffer, costs will increase, and morale will decline. So, what can your team do?

The software development process must be openly discussed with all parties having a vested interest in it — developers, testers, stakeholders, end users, and managers. Everyone needs to buy in to the approach. Everyone needs to understand their roles and responsibilities.

I’d rather sacrifice some process agility in the interest of engaging the key players rather than argue for a more agile approach that alienates some of them. Here’s my recommendation:

1. Start small. Don’t try to change too much at once.
2. Move fast. When you obtain agreement on a change, take immediate action.
3. Demonstrate success. Make noise. Get the word out regarding improvements.
4. Keep evolving. Build on success and keep changing the process.
5. Keep succeeding. Focus on low-risk changes and a continuous improvement mentality.

photo credit: marsmet544 via photopin cc

Stories: The 6th (and Final) Level in Building a User Story Roadmap

This is the seventh in a series of posts that began with “How to Capture Software Requirements Using Story Roadmaps”. The focus of this final post is the user stories.

If you’ve been following this series since the beginning, you already know how to write good user stories. The INVEST model coupled with the standard agile story format is all you need to get started. (Of course, you’ve defined the goals, stakeholders, needs, themes and epics, right?)

For those who joined this series late:

The INVEST model describes user stories as Independent, Negotiable, Valuable, Estimable, Small, and Testable.

The standard story format is “As a <role or persona>, I want to <accomplish something>, so that <benefit or reason>”.

I won’t bore you with a detailed explanation of how to write user stories. If you’re looking for a beginner’s guide start here. If you have questions, leave them in a comment to this post and I’ll try my best to answer.

Follow the User Story Roadmap

My objective in writing this series of posts has been to get you thinking about a disciplined and structured way to approach user stories. Diving into stories and rushing to implement some code doesn’t work for enterprise software projects. Leave that approach for quick software changes or simple software utilities.

Enterprise software demands a top-down approach as I’ve outlined in this series. The one exception to that guideline is the spike. What is a spike? A spike is a special type of user story. It’s an experiment and the resulting code is often thrown-away.

Spikes are a way for the team to try out an idea, test a hypothesis, or run an experiment. Spikes are a great way for teams to better understand a problem definition or a solution space. Spikes generally take a vertical slice through the target system. In other words, spikes cut across the software system rather than simply exercising an isolated portion of it.

So spikes don’t need a roadmap. Business solutions do.

The user story roadmap is now complete. We have covered Goals, Stakeholders, Needs, Themes, Epics and Stories. I hope this roadmap approach helps you build great software. The world needs more great software and lot less crapware!

photo credit: The hills are alive via photopin cc

Epics: Building a User Story Roadmap – Level 5

This is the sixth in a series of posts that began with “How to Capture Software Requirements Using Story Roadmaps”. It started with goals and will end with stories. The focus of this post is epics.

If your software development team has gotten this far along on the User Story Roadmap, the epics should be readily apparent. The team has developed a good understanding of what the project must achieve and who it must satisfy. Those are giant strides!

Now it’s time to articulate what the software will do when driven by user actions.

Epics follow the standard agile format for writing user stories:

“As a <role or persona>, I want to <accomplish something>, so that <benefit or reason>”

So, if epics follow the same pattern and format as user stories, what’s the difference?

The difference lies in the size and complexity. Let’s go back to the INVEST model for writing user stories. INVEST is an acronym for Independent, Negotiable, Valuable, Estimable, Small, and Testable. It’s good advice when applied to stories.

As for epics, they too should be Independent and Negotiable. However, they are not necessarily Estimable or Small. They have to be Testable, of course, but the testing will likely need to be broken down into smaller chunks (and aligned with stories).

So epics fail the INVEST test but that’s good. You’re still in the process of drilling down into the software details. You’re not at the user story level yet.

Let’s go back to our example retailer and its project to build an online ordering website. One epic might read like this:

“As a new customer, I want to create an account, so that I can save time when placing orders.”

Why isn’t this a user story? It’s too big. Creating an account means entering name, billing address, shipping address, phone, email, credit card information, password, and possibly other details. Credit cards need to be validated and verified. Email addresses need to be confirmed. Invalid or duplicate data entries need to be marked, then corrected. There’s a lot to do!

This is far too big to pass the INVEST test. In fact, depending upon the complexity of the final system, the team may opt to split this epic into two or more epics. For example, there could be more than one type of customer or account.

Don’t seek perfection!

The epics won’t be perfect on the first pass. That’s okay. As the software system takes shape and additional clarity is gained, some epics will be split into two or more epics. Some may be discarded and redefined. Eventually, they’ll evolve into user stories that the team can implement within sprints.

As long as the epics remain in the product backlog, the team can create, update and delete them as needed. Once they are broken down into stories AND allocated to a sprint, it’s showtime!

The user story roadmap is nearing completion. We have Goals, Stakeholders, Needs, Themes and Epics. In the next post, I’ll conclude this series with User Stories.

photo credit: See-ming Lee via photo pin cc

[The next post in this series is available here.]

Themes: The 4th Level in Building a User Story Roadmap

This is the fifth in a series of posts that began with “How to Capture Software Requirements Using Story Roadmaps”. The focus of this post is themes.

Agile software development projects usually rely on user stories as the primary vehicle for capturing software requirements. Yet, user stories are often criticized for being disjointed and confusing. Here’s why that happens.

There is a strong tendency among agile software development teams to define a software vision and immediately dive into user stories. That approach can work for small projects because it’s fairly easy to envision and comprehend the finished product.

But for enterprise-scale projects, jumping into user stories is a flawed approach. There are too many features and functions in a large-scale software application — too many stories. Every time a new story is written, two more emerge. Getting all the stories to fit together cohesively can be a monumental task.

Let’s step back and take a top-down approach to evolving the user stories via themes and epics. First, a few definitions will help clarify the discussion:

User Story

A user story is a specific action taken by a user to achieve a desired result. You’ve likely read that user stories need to be independent, negotiable, valuable, estimable, small, and testable (the “INVEST” model). It’s good advice.

Epic

An epic is a group of related stories. Like stories, epics capture user actions and results but they do so at a higher level. Epics are too big to be written and tested by a single developer within a few days. They don’t meet conditions of the INVEST model.

Theme

A theme is a high-level software objective encompassing multiple epics. Themes may span more than one project or product. Themes help to drive software strategy and communicate a clear direction. They can be viewed as implementation goals.

I’ll return to the example I’ve used throughout this series of posts. We have a local retail chain that wants to allow customers to order products online. The retailer already has a web presence but it’s for marketing and advertising only. Online ordering is a new capability.

What would some possible themes be for this project?

Theme 1: Customers want the ability to view products available for purchase.

There are many possible software implementations for browsing, searching, sorting and selecting products. Those implementation options will be covered in epics and stories.

Theme 2: Shoppers want to have a shopping cart as they navigate the site.

Shopping carts are a standard feature of virtual retail websites. Implementing them involves a lot of user activities including adding items, removing them, changing quantities, emptying the cart, saving the cart for a return visit, etc.

Theme 3: Customers want the option of registering with the site or simply making a one-time purchase without registration.

User registration, payment options, order tracking, etc. are complex topics — too complex to be covered by a single story or epic.

As you can see, themes help to group software functionality into manageable chunks. Think of a theme as a goal for one aspect of the software implementation. Themes will drive the minimum marketable feature set and help the team to focus and deliver what really matters.

Themes can also be used to focus the team’s activities during sprints. Having each sprint operate around a theme will help the team operate cohesively.

The user story roadmap has come a long way. We have Goals, Stakeholders, Needs and Themes. In the next post, I’ll discuss Epics in more detail.

photo credit: Nina Matthews Photography via photo pin cc

[The next post in this series is available here.]

Needs: The Next Step in Building a User Story Roadmap

This is the fourth in a series of posts that began with “How to Capture Software Requirements Using Story Roadmaps”. The focus of this post is stakeholder needs.

Now that you know the goals of the project and who really cares about reaching them, it’s time to consider needs. Every stakeholder has needs. If the project can satisfy those needs, success is likely. If the needs are not satisfied, the project fails.

Needs are related to business requirements but they are not identical. Needs are a higher level concept than requirements and relate more directly to people rather than software.

Let’s go back to my example of a local retail chain that wants to allow online ordering. Here are examples of possible stakeholder needs for such a project.

Marketing Manager: A competitor advertises heavily that it offers online ordering and our retailer does not. This stakeholder needs minimal online ordering capability to respond to the competition’s claim. This is a situation where agile software development helps. The team should deliver basic online ordering, then rapidly enhance it through a series of iterative deliveries.

Finance Manager: Cost control is of paramount importance. One of the reasons for offering online ordering is to reduce costs. This manager needs to show cost reductions. This likely means that order processing needs to be automated. Orders may need to be aggregated and sorted to minimize the time and cost of fulfillment.

Major Customer: This person frequently buys the same items on a regular basis. She needs the ability to create a shopping list, save it, and re-order from it. If the team focuses on high-volume stock items, it can deliver a limited solution quickly. As above, the team can iterate over a series of rapid improvements.

Make sense? Stakeholder needs have to be addressed. If the team doesn’t meet those needs, they’ll lose stakeholder support and the project could be cancelled. Another danger lies in a disgruntled stakeholder who may try to obstruct the project.

Get to know your stakeholders and work hard to meet their needs. They’ll reward you with their support and encouragement helping to make your project successful.

The user story roadmap is taking shape. We have Goals, Stakeholders and Needs. In the next post, I’ll discuss Themes.

photo credit: Daquella manera via photo pin cc

[The next post in this series is available here.]

Stakeholders: Building a User Story Roadmap

This is the third in a series of posts that began with “How to Capture Software Requirements Using Story Roadmaps”. The focus of this post is stakeholders.

The importance of stakeholders in any enterprise software project cannot be overstated. Let me say that again … The importance of stakeholders in any enterprise software project cannot be overstated.

What is a stakeholder? In the context of software projects, we are interested in business people who have an interest in the project. Stakeholders care about project outcomes. They want the project to succeed. If your project has no stakeholders, why are you bothering? No one cares!

Another group that I’ll include as stakeholders is end users — the people who use the software. For internal IT projects, stakeholders and end users often overlap. For customer-facing software, they are different groups though someone in the stakeholder group needs to be the voice of the customer. Ideally, customers will be directly involved in the project as there is no substitute for customer feedback.

Of course, stakeholders and customers don’t always agree amongst themselves. They may not agree on what the software must do or what platforms it must support. That’s okay. It’s the Product Owner’s responsibility to sort out the differences and determine what really matters.

One additional and critically important stakeholder is the executive sponsor. This person is a fairly senior executive in the company, usually a vice president. She can obtain funding for the project, marshal resources, and clear roadblocks. Major initiatives require executive sponsorship. Don’t start an enterprise project without one.

Can you identify the stakeholders for your project?

A key metric for stakeholders is their level of engagement. It’s not enough to say “Oh, sure. I’ll participate.” Stakeholders need to contribute. They need to be involved in the project early and stay involved throughout. They need to display genuine enthusiasm for the team’s efforts.

Stakeholders will relate to the project goals. Don’t be bashful about wording goals in such a way that they target specific stakeholder types. It’s all part of building support for the project. The stakeholders will often self-select themselves by virtue of expressing an interest in the project outcomes.

The user story roadmap is beginning to take shape. We have Goals and Stakeholders. In the next post, I’ll discuss Needs.

photo credit: francistoms via photo pin cc

[The next post in this series is available here.]

Business Goals: Building a User Story Roadmap

This is the second in a series of posts that began with “How to Capture Software Requirements Using Story Roadmaps”. The focus of this post is business goals.

Every project needs a goal or a set of goals. These are high-level descriptions of the context for the project and the business value to be delivered.

I see many projects undertaken without goals or with goals that are so vague as to be worthless. Goals do not need to be measurable but they need to be clear.

Let’s take the example of a local retail business. This is a bricks-and-mortar establishment selling retail goods through several outlets. The company decides to allow customers to order goods online.

Goal: Allow customers to order online.

Really? That’s a vague goal. What is the business value proposition? Why is the company implementing online ordering?

Goal: Allow existing customers to order online to make shopping with us more convenient.

The value proposition in this goal is customer retention. It’s about offering multiple shopping options and building relationships with customers.

Goal: Enable customers to order online to reach beyond our current local markets.

Clearly the value in this goal lies in attracting new customers. The company is looking to expand its operations and enter new markets without having to build new stores.

Goal: Enable customers to order online and pickup items in any store.

This is also a customer relationship goal. It presents a new technical challenge in that the shopping website will need to integrate with inventory information for each store.

You get the idea. Goals are broad and somewhat subjective. They establish context and begin the process of drilling down into the problem space to define exactly what the software must do.

Goals form the beginning of the user story roadmap. Diving directly into user stories without establishing goals will only cause confusion and arguments. The next post in this series will lead us further along the roadmap by discussing stakeholders and end users.

photo credit: Krissy.Venosdale via photo pin cc

[The next post in this series is available here.]

How to Capture Software Requirements Using Story Roadmaps

There’s much disagreement among software practitioners about how to capture requirements. Some argue in favor of lengthy, detailed documentation. With equal vigor, others argue in favor of simple tools like user stories. What should you do?

There are valid arguments on both sides. Detailed requirements documentation can supply levels of insight that are hard to capture any other way — at a price. The documents will be complex and labor intensive. They are often hard to understand and difficult to maintain as requirements change.

User stories, being simple and fluid, can be easy to grasp. Any user story can be read and understood in isolation. The down side is that the stories can be difficult to stitch together. Many people will have a hard time seeing the big picture representing how the software elements fit together.

You need a story roadmap.

Stakeholders and end users need to comprehend both the big picture view and the user interface details. System designers and developers need a simple and effective way to capture the system requirements. Here’s how to do both — create a roadmap.

I favor the user story approach because I believe the stakeholders and end users can more readily relate to the resulting requirements. However, the stories need to be written and presented in a hierarchical fashion as follows:

Level 1 – Business goals: Why is the project being done? What are the desired business changes and outcomes? Put the goals at the top of the roadmap so you can keep them at top of mind. Goals must have business value and must be measurable. How will you measure how each delivery matches the expectations?

Level 2 – Stakeholders: Who are the people that can facilitate the desired outcomes? Who can contribute to the goals? Who are the people that will be most affected by the software? Separate the stakeholders and end users into groups based on roles.

Level 3 – Needs: For each group, how can the target group contribute to or obstruct the desired outcome? This will help in defining stakeholder and end user priorities.

Level 4 – Themes: Now that you’ve defined goals, people and needs, begin the process of showing what the software has to do. What are the business activities or software capabilities that would support the needs of the stakeholders and end users? For each theme, what are the minimum marketable features?

Level 5 – Epics: For each theme, what are the user activities that need to be supported by the software? These are business activities not point-and-click actions. The epics will be divided into user stories small enough to be implemented within a sprint.

Level 6 – Stories: For each epic, what are the user actions that need to be supported by the software? This is the lowest level. User stories will be implemented during sprints.

Over the course of several blog posts, I’ll elaborate on these levels. Hopefully you’ll conclude that user stories are a superior way to capture software requirements — when they are defined in a hierarchical fashion.

photo credit: espresso marco via photo pin cc

[The next post in this series is available here.]