by John Parker | May 16, 2014 | Agile, Uncategorized |
There were a few great questions asked at the end of our webinar yesterday, Agile Business Transformation. While I didn’t have time to answer them in the information-packed webinar, here are your answers. Q: Does Enfocus know of publications on Agile transformations for business with products with HW as well as SW products? A: –Agile Development has been used for both the development of hardware and software products. One of the best-known examples is the development of Nokia phones. In Enterprises, many infrastructure groups are also starting to use agile. Many organizations are starting to adopt DevOps which is an umbrella concept that refers to anything that facilitates a smoother interaction between development and operations. The best information for large agile transformations is at www.scaledagileframework.com. There is also a major movement toward integrating Lean with agile and there are several good books on this subject. A very good book on this subject is Implementing Lean Software Development: From Concept to Cash by Tom and Mary Poppendieck. Q: I find it challenging to differentiate a Feature from An Epic! For example, how would you determine if a BR is a feature or an Epic? A: — Great Question. A feature has to be small enough to fit into a Release. An epic spans multiple releases. Epics are approved by Portfolio management, whereas Features are defined by program management and are used to decompose an Epic into manageable components. View an epic as a project and a feature as a component of a project. Q: Most of the time, we find the stories changing to be a Feature or Epic! A:...
by Jenny Boronyak | Feb 11, 2014 | Business Analysis, Uncategorized |
User stories provide agile practitioners with great success because they help focus on the value being delivered to users. As Mike Cohn writes in his book, User Stories Applied: For Agile Software Development: “Rather than allowing product backlog items to describe new features, issues to investigate, defects to be fixed, and so on, the product backlog must describe some item of value to a user or to the product owner.” And that’s why a key component to agile software development is effectively managing the user story backlog. Typically in an agile operation, an initial set of user stories is defined as part of the discovery process, and additional user stories are continuously added by the team as needed during delivery. Defining user stories is a convenient way of capturing requirements at a high level of detail while focusing on user goals—which is why they can be so successful at helping you determine what is valuable to your uers. Good user stories are much more than just statements. A good user story consists of three elements, commonly referred to as the three C’s: 1. Card The user story should be able to fit on a 3”x5” note card, efficiently capturing the most important information. While this “C” sometimes refers to an actual note card, we mean it to refer to the optimal size of a user story. As Jeffries writes, the card should not contain all information about the requirement, but rather just enough to be used in planning to identify the requirement and remind the project team of the story. Each user story should follow the standardized format of:...
