by Jenny Boronyak | Dec 29, 2014 | Business Analysis, ITIL and Service Design |
As organizations search for new ways to deliver solutions and increase customer satisfaction, many have turned to the discipline of IT service design. But still, many organizations haven’t made the transformation yet—big mistake! Don’t take our word for it; hear what the experts have to say about what exactly service design is, and why it is so important to the success of the company: What is service design? “The objective of ITIL Service Design is to design new IT services. The scope of Service Design includes the design of new services, as well as changes and improvements to existing ones… Service Design identifies service requirements and devises new service offerings as well as changes and improvements to existing ones.” – IT Infrastructure Library “Service design is sometimes easiest to grasp when contrasted with product design. Product designers create tangible things such as bikes, cars, coffee machines, MP3 players, and laptops. Service designers create intangible experiences, such as the series of interactions that you have as you book a flight, pay a bill, get a driver’s license, or visit a doctor. Service designers also design the behind-the-scenes activities that enable those experiences to be delivered as planned.” – Kristina Dervojeda, et. al., Design for Innovation: Service design as a means to advance business models “Service design applies design methods and craft to the definition and orchestration of service experiences. Service design examines the operations, culture, and structure of an organization for impact on service experience.” – Jamin Hegeman, 5 Things I Wish I Knew: A Service Design Journey “Service design is a relatively new discipline that asks some fundamental questions:...
by Jenny Boronyak | Dec 10, 2014 | Agile, Business Analysis, Collaboration, Product Development, Project Management |
A clearly-defined Definition of Done is absolutely essential to agile software development. At the end of every sprint or increment, software is demonstrated to the product owner and relevant stakeholders to make sure that the increment is done. But too often, we end up accepting the work completed during the increment even though it isn’t truly done yet – “DONE-done,” as we call it at Enfocus Solutions. A Definition of Done creates a shared understanding of what it means to be finished. According to AgileAlliance.org, the Definition of Done is a list of criteria that must be met before a product increment is considered “Done.” The Definition of Done is also an expression of the team’s quality standards. A more precise Definition of Done is often associated with the delivery of higher quality solutions. Generally, the team will increase their velocity as their Definition of Done gets refined, because they will improve release planning and spend less time fixing old problems. The most important function of the Definition of Done is that it provides a clear description of what it means for an increment to be done and ready to be implemented. It helps us avoid misunderstandings and miscommunications, and makes sure that there’s transparency around what the team is doing during the sprint. It is difficult to pin down a Definition of Done that suits all circumstances. Each organization needs to define their own definition; the checklist found in this pocket guide is meant to serve as a guideline for building your own Definition of Done for an iteration. Here’s a couple tips for dealing with the Definition...
by Karl Wiegers | Nov 7, 2014 | Business Analysis, Collaboration |
The business requirements will help the business analyst identify potential user classes for the product. The objective of exploring user requirements is to understand what members of these user classes expect to be able to do with the product and how the product will let them achieve specific goals. The user requirements must align with the higher-level business goals captured in the business requirements. Some user goals might pertain to tasks the users must perform; use cases often are an effective way to record these tasks. Other user goals, though, might indicate the importance of specific nonfunctional requirements. Examples include the ability to complete a task within a certain length of time, and the ability to access a system remotely from a smart phone. Therefore, user requirements also encompass the users’ expectations about performance, availability, usability, reliability, and other quality attributes. It’s also important to surface pertinent business rules, design and implementation constraints, and assumptions the various stakeholders might be making. The objective is for the BA to understand what customers are envisioning so he can record both functional and nonfunctional requirements that will guide the development team’s work. Furthermore, documented requirements and user acceptance criteria will help testers determine whether the delivered product satisfies its requirements. When eliciting user requirements, the BA typically works with a number of key users who represent specific user classes. The BA needs to ask questions that will help those users describe the goals they want to accomplish with the help of the system. For most types of software projects, this is far more valuable than the traditional focus of requirements discussions on...
by Karl Wiegers | Nov 4, 2014 | Business Analysis |
“Why?” is an excellent question to put in the business analyst’s bag of tricks. During a reengineering project, a BA named Dawn asked one of the developers why a utility company fee calculation was being performed a certain way in the existing system. “There’s a government statute that dictates how we have to calculate these fees,” was the reply. Upon investigation, Dawn discovered that in fact the current system had not implemented the computation correctly according to that statute. The system had calculated these utility fees incorrectly for an embarrassingly long time. This discrepancy never would have come to light had Dawn simply accepted the stated need for the current formula. Asking “why” revealed a major error that the replacement system corrected. The shrewd BA asks why a lot. It’s important that “why” explorations be expressed in a way that doesn’t sound confrontational, accusatory, or challenging. I often ask questions that begin this way: “Can you please help me understand…” This phrase is longer than why and means essentially the same thing, but it has a more collaborative feel to it. When a user representative presents a requirement that contains an embedded solution idea, asking why can let you know whether the solution idea is a true design constraint or just an idea or suggestion. Asking why several times in succession is a way to drill down from a superficially proposed customer “want” to the real underlying need. This helps the software team address the real issue, not just a superficially presented issue. Gently probing with why can reveal other sorts of useful information: The answer to why might...
by Karl Wiegers | Oct 30, 2014 | Business Analysis |
This article (adapted from my book More About Software Requirements) presents several sets of questions the business analyst might consider asking customer representatives during a discussion about user requirements. Don’t use these questions as a script to be followed by rote in an elicitation workshop. Instead, look for ways to build these sorts of questions into the natural flow of a requirements exploration. What are some reasons why you or your colleagues would use the new product? These “reasons to use” could become candidates for use cases. They might identify business tasks or objectives that members of a particular user class might need to achieve from time to time. What goals might you have in mind that this product could help you accomplish? Use cases normally are directed toward helping the user achieve a specific goal. The name of the use case indicates the goal the user has in mind: Print a Boarding Pass, Withdraw Cash, Submit an Employment Application, and so on. What problems do you expect this product to solve for you? Understanding the problems and limitations the users perceive in their current environment helps the business analyst determine appropriate capabilities for the new system. This question also helps determine whether the end users’ objectives for the system align well with senior management’s objectives, as captured in the business requirements. If not, you need to iterate between the business requirements and user requirements to align expectations. What external events are associated with the product? BAs sometimes use the term business event to describe the triggering condition that launches execution of a use case. Perhaps a help desk...
by Karl Wiegers | Oct 28, 2014 | Business Analysis |
An effective business analyst is not simply a scribe who records whatever customers say. The BA needs to stimulate the thinking of the people he’s interviewing to get below the surface. The BA should ask questions such as “What else could happen that we haven’t already discussed?” and “Would anyone ever want to <do something>?” and “Could <some condition> ever occur?” These are ways to discover possible lower-probability scenarios or options the system should provide to the user. In their classic book Exploring Requirements: Quality Before Design (Dorset House Publishing, 1989), Donald Gause and Gerald Weinberg describe “context-free questions.” In their words, context-free questions “are high-level questions that can be posed early in a project to obtain information about global properties of the design problem and potential solutions. Context-free questions are completely appropriate for any product to be designed….” The BA can use such questions to explore both processes and products. They’re a valuable complement to specific questions about the capabilities and characteristics of the product being specified. In my experience, requirements elicitation discussions typically emphasize the expected normal behavior of the system. However, anyone who has ever done any programming knows that a good developer writes a lot of code to deal with exception conditions. An important aspect of requirements elicitation is to identify things that could go wrong, determine how the system should detect an error, and describe how the system should respond to the error. As a BA, you need to probe around the exceptions during your requirements discussions. Ask questions such as “What should happen if <some error condition arises>?” This is a way to...
