CMSI 543 / SYEG 557: Welcome to Week 07

This Week's Class Agenda

Mid-Term Examination

The mid-term will take place at the start of class and will run until 7:30. You will have a full one and one-half hours to complete the test. You may ask me questions during the exam if you need clarification only. The test is CLOSED BOOK, CLOSED NOTES, CLOSED COMPUTERS, CLOSED CALCULATORS, and CLOSED NEIGHBOR. Please complete the test by yourself. There are 100 total points. BE SURE TO SHOW YOUR CALCULATIONS WHERE APPLICABLE for partial credit!

DON'T STRESS! If you have been in class and paid attention, reviewed the recorded videos, read the assigned readings, and done the homework, you will have no problem.

Requirements ~ Continued

Why do we need requirements… anyhow?

As we've seen, getting software to provide business value to a customer is hard. Making sure that the software we produce actually provides the customer with the business value that they need is even harder than that. In order to maximize the chances of producing something the customer actually needs, we must have some idea of what that will look like. In addition, we need to have some way of testing if we have built the right thing, then to ensure we have built the thing right. This is one of the main functions of requirements.

Additions and Considerations from Other Agile Methods

Extreme Programming [XP]

XP calls the requirements user stories just like Scrum does. However, with XP, the user stories are optimally written by the customer or their representatives. Further, XP also puts high value on the user stories for purposes of estimation, so that the team can understand the scope of what is being requested and thus needs to be built.


Dynamic Systems Development Method [DSDM]

DSDM specifically focuses on building critical functionality first. To do that, the requirements are evaluated on a four-tiered assessment known as MoSCoW. The letters are capitalized because they relate to the four tiers of the evaluation:

Crystal Family

Crystal is much more focused on usability, and thus takes a user-centric approach to requirements. The philosophy is quite different than XP or Scrum, so the requirements stress ease of use.

Feature Driven Development [FDD]

FDD is essentially the same as Scrum. It stresses user stories that are small, high in client value, and can be implemented in a short period of time, typically one sprint. FDD user stories are slightly different, though, with a format of:

<Action> the <Result> by|for|of|to <Object>

…so a typical user story might read:

Calculate the total of a sale.

Lean

The Lean approach to requirements is very different and innovative. We'll check that out at the bottom of the page, so stay tuned, sports fans!


Enhancing Requirements

Incorporation of Personas

One way to enhance requirements is to incorporate personas into the user stories. What is a persona you may ask? It is a fancy-schmancy word for a FICTIONAL representation of a user who would be using your system. This representation can be helpful in walking through user-based operations to help guide decisions about the product, its features, its visual look and feel, and ways to navigate or operate it. [from Grosjean 2009 in Ashmore p 126]

Some specific guidance on making personas, as suggested by Grosjean, are as follows:

Personas can be just as important to the team as they are to the PO [who is responsible for making them] since it helps team members connect with exactly what the end users want and need, so the tendency to build something generic can be resisted more effectively.


Human–Computer Interaction [HCI] and Usability

Another good way to improve user stories is to add usability, by considering human-computer interaction [HCI]. The idea here is to construct wireframes or prototypes that can be done on paper or in other ways that involve only minimal development. These prototypes are then shown to the PO and the end users so they can react and provide feedback. Since at this point there is no code written, these prototypes are cheap and easy to change, but yet they allow the development team to have a MUCH cleaner idea of what the customer needs.

In the ideal situation, the HCI designer will be part of the scrum team so that they are available to ask and answer questions or clarify items for features that are being developed. Because HCI designing often is a long process, it is important for the HCI designers to be at least one to two sprints ahead of the rest of the development team.

Human-Computer Interaction graphic

Business Value

THE POINT OF ALL USER STORIES IS TO DRIVE THE APPLICATION TO PRODUCE BUSINESS VALUE. The term can be applied to many different things:

Adding Business Value
  • Increasing company revenue
  • Expanding the market for the product by adding new features
  • Lowering costs to the organization
  • Improving customer satisfaction with the product
  • Speeding up the application or optimizing its processing
  • Making the product more stable or robust in its operation
  • Improving the products' usability and/or ease of use
  • Improving the product's percieved usability

Our user stories should always be evaluated to ensure that they are producing and delivering business value to the cuxtomers and users. If a user story does not fit this basic criterion, it should either be re-prioritized [to make certain that higher-valued features are worked on first] or should be taken out of the backlog altogether.

Note that it can be somewhat difficult to tell what is a low-value item from a high-value item when the PO is defining a product. This is another area in which personas can be helpful. The prudent PO will always be looking at the user stories to make sure they are providing value, so that the team doesn't wind up working on something that will target 1% of the market over something that will address 99% of the market.


From User Stories to Deliverables

Release Management

Another critical activity of Agile, and with ANY software project in point of fact, is the answer to the question, How do we release the product, and how do we manage it once it is released? Because user stories are small, and [barring negative feedback] are completed in a single sprint, there may not be enough of the product to release a new version at the end of every sprint. It is common, therefore, to save up several sprints' worth of code to release all at once time so there is enough to consider it a product. This is often done on a time-scale basis, with quarterly releases or twice-a-year releases. It is part of the PO's job to determine the right amount of product to put into a release. There are, of course, several factors to consider:

There are other questions as well.

Managing Features

There is essentially a three-way matching exercise in Agile which is a challenge to the PO and the team. Delivery dates need to be matched with the marketplace needs, which need to align with the customer's business needs, which must also line up with the needs of the development team to iteratively create the product. Customers will want to know what features will be included and when they will show up.

One way to manage this situation is to start with a small number of features which will be included in the initial product launch. By having a good handle on this set, everyone can agree on a time for the release, giving the customer's marketing department the runway to prepare announcement materials, and other members of the product process [such as maintenance and support] can also have time to be ready.

One thing that makes this easier is to have the features defined, but NOT have them defined with too much detail. This method provides the feature defenition at the level of granularity required by [for example] the marketing department, without having to define every minor detail of the feature at the outset of the development effort, so that the Agile philosophy of iterativeness is supported. Several elements come into play here:

  • Define features to which you are willing to commit; a good number is three compelling and broadly defined features which leave some wiggle room within the scope.
  • Let the sales and marketing departments hit the marketplace with the committed features and the projected timeline
  • Manage expectations between the team and the PO with respect to their expectations for each of the features; be ready to narrow the scope if necessary as complexities or challenges arise.
  • DELIVER ON TIME! Once the product is launched, add back any features that were removed in the next release or two.
Watch the Work Product, Not the Worker!

Customer-Specific Code

Yet another complex situation in Agile is the fact that for any given product there will most likely be a subset of the code which is specifically dedicated to a single customer's requirements or product. This is a natural offshoot of the customer-supplyer process, since the customer wants to receive what they are going to pay for, without a lot of extra features that might make the software product more generic so that the development organization can potentially monetize it for other customers. The process is a challenge to the Agile process, because it is typically time-bound [meaning there are strict schedules to meet] and the scope must be defined and agreed to by all parties at the beginning of the project. These projects tend to be more Waterfall in nature than Agile methods will easily support.

Nevertheless, Agile philosophies can be applied. First express the requirements as user stories rather than strict Waterfall numbered requirements, which will help to foster discussion and collaboration. Next, MAKE SURE the customer knows the iterative nature of the development, and let them know they will be part of all decisions to provide transparency into the process. Invite the customer to the post-mortem and demonstration. If changes are needed or requested which require scope changes to the project, have the PO and the team CAREFULLY evaluate the customer feedback that is driving those changes.

The following table which appears on page 132 of your text book, provides some good do's and don'ts of customer-specific code.

DODON'T
Commit to featuresAdjust the scope without the involvement of the account management team
Document the requirements in user story format Commit to a date that is optimistic given current resources and conditions; make sure that dates can be reasonably met
Be transparent about development progressing in a series of sprints Agree to user stories or requirements that are vague in nature or could be easily misinterpreted
Consider inviting the customer to the Sprint demonstrations/reviews

Communication

Sharing the Vision

Effective Agile projects are focused on effective communication. Here are a few things to keep in mind with respect to Agile organizations. The team, PO, stakeholders, and other roles must all understand the project vision completely for what will be included in the releases. The job of making sure this happens usually falls to the PO.

One best practice to consider is meeting with everyone who may be affected at the very beginning of the project; this meeting is often called a kick-off meeting. Even so, benefit can be gained from having any kind of team meeting at which everyone gains a common understanding of the goals and the business value that is the object of the product. For example, one of the last things that the team might tackle is reporting, which comes near the end of the process; however, there may be parts of the project that have a direct bearing on reporting, such as what data is being stored, how long it will be stored, and who will have access to it at what level.

Sharing the project vision with all involved stakeholders has the added benefit of forcing the PO to HAVE a project vision to begin with.

You can quickly grasp the important difference between leadership and management if you envision a group of producers cutting their way through the jungle with machetes. They're the producers, the problem solvers … The LEADER is the one who climbs the tallest tree, surveys the entire situation, and yells, WRONG JUNGLE!! [Covey 1989 in Ashmore p 133]

We want our Agile PO's to show true leadership over their product by having an appropriate vision that is shared with all stakeholders.


Roadmaps — Internal and External

An external roadmap is a way of looking at what new products or new features will be brought to market by a specified date. The date can be short-term or long-term, but the roadmap serves to help focus the orgainzation's efforts. Roadmaps are most often strictly for internal use within the organization; it is rare to find them, for example, on the organization's web site. External roadmaps give broad explanations of what is coming down the pipe, and usually in fairly broad time increments of quarters or years.

What do we do NEXT!?!

Agile is supposed to be iterative and able to adapt to constant change. However, organizations need to have some kind of long-term plan for their business or operations; in fact, many of an organization's customers may even expect that situation.

There are two general types of business model that will be found in roadmaps: business-to-business or B-to-B [or sometimes B2B] and business-to-consumer or B-to-C [or B2C].

An internal roadmap is very similar to its external counterpart, but with a focus on the organization, not the marketplace. It is usually somewhat easier to make than an external roadmap as well, since it doesn't represent anything with respect to existing clients and thus needs only to focus on what the organization itself wants. The PO will likely use the product backlog, features, and delivery dates. In addition, most of the other parts of the organization will only need to know the plans in general terms, so the roadmap doesn't need specific details of user stories; those parts of the organization can be satisfied easily with epics.

In either case, external or internal, what is required is a clear owner of the responsibilities for the updating of information, the schedule for such updates, and communicating the plan and vision to the rest of the organization. Typically these jobs fall to the PO or PM.


Lean Development and MVP

The concept of Lean software development was adapted from the manufacturing environment at Toyota Auto company. The engineers there were looking for a way to manage the supply chain for their production by giving their workers the power to be part of decision-making, to control production sizes and cost, and to reduce inventory. All these activities save the company significant expenditures and help to speed up the time required to produce their products.

Lean handles requirements in sort of a hybrid approach between Agile and Waterfall. Often they are written as formal requirements as we've seen above, and are managed with a formal process. However, within that context, a less formalized feedback process is involved, which gives the production team much more flexibility to improve the process over time, including working with the requirements as user stories so that the actual requirements become more apparent.

The same principles, then, can be applied to software development. There are seven basic principles that are part of the Lean method [Poppendieck 2003 in Ashmore p 137]:

The reason lean agility is important, according to [Ries 2011], is that markets change so rapidly that product development has a hard time keeping up. One way to help the situation is to produce something called a Minimum Viable Product or MVP. This contains the minimum number of features that are required to address some marketplace need. The MVP can launch with that very minimal product, so as to get to market early, and still have enough flexibility to see how the market responds and reacts. In the case where the MVP is successful, continued development can proceed, adding more new features and releasing the next MVP. However, if the market responds unfavorably, only minimal effort and resources have been expended, and the organization can decide whether to put more effort into that product to better address the need, or to drop that product and move on to something else. Reis called this tactic pivot or persevere.

The goal of an MVP is *NOT* to launch a fully-functional product with all features; rather, it is intended to be a way to get SOMETHING into the market, which contains the features that deliver the most business value, and the highest Return On Investment or ROI. When feedback from the market is obtained rapidly, the PO and development team have a chance to continually change, adapt, and improve the product.

Coming up…

SPRING BREAK!!!!!