Stakeholders

A stakeholder can be anybody outside of the development team who has a vested interest in the outcome of a software development project. For example, the end users of the software are certainly stakeholders and are perhaps the first group who comes to mind when you think of stakeholders. Another stakeholder may be the person who is funding a particular project. After all, end users may want an application to have a key piece of functionality, but if the person paying for the project believes that it is too expensive to implement then that's important for the software development team to know before they start writing code. A lawyer may also be a stakeholder because some applications may need to undergo scrutiny to ensure that certain compliance and regulatory requirements are met. If you are in the business of selling software then your product's marketing team will likely have a seat at the table. You can probably think of other stakeholders for your software as well.

Whoever the stakeholders are for your project, they are a vital part of your extended development team. Stakeholders can play a role in some or all of the following activities:

• Requirements elicitation—This is the process of gathering requirements from stakeholders through brainstorming, focus groups, role playing, prototyping, and other techniques designed to capture what a stakeholder may need your software to do today and in the future. These requirements usually end up on a backlog, which is updated and changed throughout the development process.
• Requirements refinement—Requirements do not normally come with all of the information needed to deliver them. Sometimes they start life as short notes and the details emerge over time. There is an expression, “refined to action,” where the requirements are discussed and refined up until the point at which the development team commits to delivering them. Throughout the life of the requirements, the team works with the stakeholders to gather additional details as they are needed. As the software development team begins to capture and analyze requirements, they often turn these requirements into written specifications, use case models, visual storyboards, or other such artifacts, which attempt to capture what they heard from stakeholders during the requirements elicitation and refinement activities. This is an important point in time for stakeholders to provide feedback about the intended implementation.
• Requirements ordering—As requirements are refined, they need to be ordered. It is important to determine the most optimal order of your requirements in order to successfully deliver the highest value requirements for any individual incremental delivery. There are many things that can influence ordering, including but not limited to business priority, technical limitations, and strategic direction.
• Feedback—As working code begins to take shape, it may be possible to further refine requirements by asking stakeholders to use interim builds of your software and provide feedback. When this step is implemented early enough, it can help uncover disconnects between the stakeholder's expectations and the development team's implementation in time to affect that upcoming release milestone.

The activities described in the preceding list are typically referred to collectively as requirements management. Like other aspects of software development, requirements management is both an art and science, and it has been covered extensively by other books (Dean Leffingwell and Karl Weigers have both written great books on software requirements). For the purposes of this book, we are focusing on the tooling that is provided as part of Visual Studio for working with requirements. In this section, you learn about the PowerPoint Storyboarding add-in, as well as the Microsoft Feedback Client. In this chapter, you also learn about a few of Microsoft's partners who offer complementary products in the requirements management space. In Chapter 12, you learn how Team Foundation Server enables teams to prioritize the order in which your team will implement requirements.

Storyboarding

Storyboarding is a technique that was pioneered by the cartoon and film industry to help visualize sequences before the expensive process of filming or animating had begun. Because storyboards are composed of simple sketches, they are quick to create and easy to re-create if needed based on feedback, filming constraints, script changes, and so on. After the director is satisfied with the overall flow represented by the storyboard, the expensive processes of designing sets, configuring shots, filming, editing, and so on can begin.

Storyboards have since found their way into software user interface design. A series of storyboard panels could show the way in which a user interacts with a website when researching and ordering a new coffee table. The storyboard can then be shared with prospective users, market researchers, information architects, and other stakeholders and experts whose opinions help to shape the storyboard into the best possible design for the software development team to implement. The storyboard then becomes an artifact that the software development team can use to help plan their implementation.

With Visual Studio 2012, Microsoft released a new tool for creating and sharing storyboards and it has stayed pretty much the same in Visual Studio 2013. This tool is known as PowerPoint Storyboarding, and, as the name implies, it is based on Microsoft PowerPoint. In Chapter 9, you learn about the capabilities of this tool and how to use it to efficiently and cheaply iterate on user interface design with your project's stakeholders prior to writing a single line of code.

Capturing Stakeholder Feedback

Wouldn't it be great if you could talk to your stakeholders about what they want the software to do, go off for a few weeks to build it, and then give it to them and smile while they congratulate you on building exactly what they wanted? Unfortunately this rarely happens in the software development world. The very nature of software development is highly complex. There are technical challenges to overcome; complex business rules and other requirements must be captured and implemented precisely; and different machine environments must be considered, such as which web browser the users prefer, what languages they speak, what accessibility constraints they have, and so on. And if all that isn't challenging enough, you have to account for the users' taste and style preferences. We have all been in this situation: You are demonstrating your software; it works flawlessly; everything is going well; and then somebody complains that they hate the font you chose for the user interface. It makes you wonder if Leonardo da Vinci ever received complaints about the frames his masterpieces went into.

But “the customer is always right,” and it is up to the software development team to listen to their feedback and respond to the best of their ability to create the best possible deliverables. The Agile Manifesto pays credence to this idea throughout, such as in the first principle:

“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”

Many agile teams even go so far as to treat the customer as an integral part of the software development team. An end user or other stakeholder may attend weekly progress reviews or even participate in discussions about possible implementations. When this type of face-to-face interaction is possible, it can be invaluable for ensuring that the vision of the software development team is closely aligned with that of the stakeholders. But how can you achieve this type of cooperation when your stakeholders are geographically dispersed, time shifted, or too numerous to practically incorporate into the regular cadence of development team meetings?

Microsoft has another tool, introduced in Visual Studio 2012, that's designed to facilitate this type of interaction. The Microsoft Feedback Client captures rich data about the interactions of a stakeholder with your software, as well as their reactions. The development team can start by initiating a request for a stakeholder to provide feedback about a user story or requirement that has been implemented. The stakeholder can then run the Microsoft Feedback Client while they are using the interim build of the software. Along the way, that stakeholder can choose to capture video and audio recordings, notes, and screenshots that reflect things that they like or dislike about your software. All of this data is centrally stored in Team Foundation Server so that the development team can analyze and react to it. You learn how to use the Microsoft Feedback Client in Chapter 10.

Work Item Only View

Although you should always use the Feedback tool for customer feedback, there is another way of collecting input from your stakeholders. You can allow them to file bugs or enhancement requests directly to Team Foundation Server. This centralizes feedback in one repository that the development team can then react to and track over time. Microsoft does this for a wide range of Microsoft products via their Microsoft Connect website (http://connect.microsoft.com). Product groups at Microsoft synchronize data from Connect directly into their own Team Foundation Server work item databases, and any responses about the customer's request are returned to the user via the public website.

You can use Team Foundation Server for this purpose as well. But for most organizations, obtaining a Team Foundation Server client access license (CAL) for every possible stakeholder can be cost prohibitive. In recognition of this, Microsoft created a licensing exemption for stakeholders who may file bugs or enhancement requests. From the Visual Studio licensing whitepaper:

A Team Foundation Server CAL is not required in the following scenarios: Entering work items through any interface, and viewing and editing work items you created. This enables users to enter and edit their own work items of any type.

Because stakeholders are not likely to have Visual Studio installed, the most common way of asking them to provide feedback in this manner is via Team Web Access, which is covered in Chapter 10. Stakeholders who don't already have access to Team Foundation Server can be added to the Limited license group in Team Foundation Server. This is also referred to as Work Item Only View. Users who are members of this group are only permitted to create and update work items they create, per the terms of the aforementioned licensing clause. If a stakeholder requires more comprehensive access to Team Foundation Server, she needs to be licensed and permissioned appropriately.

Third-Party Requirements Management Solutions

There are a number of approaches and solutions to requirements management and stakeholder engagement employed by software development teams. Although Microsoft has made forays into requirements management with the Visual Studio 2012 release, and expanded on it in Visual Studio 2013, by introducing the aforementioned tools, it continues to rely on this broad ecosystem of partners to provide complementary requirements management solutions that integrate with Team Foundation Server. Three popular examples of these partner solutions are covered next.

TeamCompanion

The single most popular work item management system on the planet is email. Your program and project managers likely live in their email, as do many of your stakeholders. It would be awesome if you could integrate your work items directly into Microsoft Outlook. TeamCompanion from Ekobit allows you to do just that. In Figure 8.1 you can see the integration with Outlook in action. Not only does it build agile planning tools right into Microsoft Outlook, but it also has tools for creating work items from emails and vice versa. Indeed, it will automatically detect if there is a work item associated with an email thread and keep it up to date. If your customer emails you about a bug or enhancement, you can easily turn it into work items in Team Foundation Server for the development team to triage and react to. Conversely, you can use TeamCompanion to generate emails from work items in Team Foundation Server—such as to provide the latest status of an enhancement-request work item to an important customer.

You can learn more about TeamCompanion at www.teamcompanion.com.

TeamSpec

One of the most widely used requirements management “tools” on the planet is Microsoft Word. Microsoft Word is popular, easy to use, and facilitates sharing and collaboration via tracked changes and comments. It's no wonder then that many software requirements live their lives as specifications in Word documents. TeamSolutions, a Microsoft partner, recognized the popularity of Microsoft Word in the requirements management space and saw an opportunity to keep requirements documents relevant by integrating Word and Team Foundation Server. They created a solution called TeamSpec to bring Microsoft Word-based requirements into a company's ALM process, and it has become popular among teams who use Team Foundation Server.

TeamSpec, shown in Figure 8.2, maintains a link between requirements in your document and pertinent work items in Team Foundation Server. One feature enables teams to compose requirements using customizable templates in Microsoft Word. The templates define fields that represent the elements of the requirement that will be mapped to Team Foundation Server. For example, the template for a user story may define fields for a title, a description, and the person on the development team responsible for that user story. The requirements document in Word can then be shared with project stakeholders for validation. The stakeholders can make proposed edits or comments to send it back to the development team just like they would with any other Word document. After the stakeholders have signed off on a requirements document, it can be synchronized with Team Foundation Server as a work item or group of work items. TeamSpec is responsible for providing this synchronization by examining the contents of each field in the document template and pushing it into a corresponding work item field.

Another capability of TeamSpec is that it can be used in the other direction to generate Word documents from work items in Team Foundation Server. This feature is especially useful when the software development team has made changes to a requirement that must be communicated to the stakeholders. In this way, TeamSpec recognizes that requirements often evolve over time and that keeping the requirements in-sync, for all stakeholders, is imperative. You can learn more about TeamSpec at www.teamsystemsolutions.com.

inteGREAT

inteGREAT, by eDevTECH (www.edevtech.com), is a requirements lifecycle management platform that integrates bidirectionally with Team Foundation Server 2013, with Team Foundation Server providing the centralized application and database store for inteGREAT. This also works with older versions of Team Foundation Server as well.

inteGREAT, shown in Figure 8.3, enables users to elicit, analyze, validate, review, and manage requirements. inteGREAT also offers bidirectional integration with Microsoft Excel and Word, allowing business users to author requirements in tools that are familiar to them. It embeds Visio controls within the tool to facilitate the creation of many types of diagrams. It also integrates with Microsoft Project, publishes documents and an HTML knowledge base to SharePoint, and produces XAML code from its screen mock-up functionality. It even integrates third-party solutions such as CA ERwin and HP Quality Center.

If you are seeking a requirements definition and management solution that allows you to baseline projects and provides a more formal and comprehensive approach than that currently offered by Microsoft, then you should consider evaluating inteGREAT.

Summary

In this chapter, you learned about the importance of engaging early and frequently with your software development project's stakeholders. During this process you capture and refine the requirements your software needs to implement before you begin coding. Then, as your software evolves, you learned about getting additional feedback from stakeholders, which can influence the ongoing implementation to ensure that the development team is building the right software. Microsoft and its partners have built several tools to facilitate requirements management and collaboration with your project's stakeholders. These tools integrate with Team Foundation Server alongside the rest of your software development project's artifacts.

In Chapter 9 you learn more about PowerPoint Storyboarding.