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:...
by John Parker | Feb 3, 2014 | Business Analysis, Uncategorized |
By proactively identifying and eliminating or remedying poorly performing application assets, Application Portfolio Rationalization helps companies to: Reduce costs, Target efforts to the areas of highest return, and Maximize the business value of their application portfolios. Globalization and changing business requirements impose significant challenges on technology leaders who are under constant pressure to both innovate and reduce costs. These demands to do more with less have been exacerbated by business leaders hearing about prospective savings from use of the Cloud without understanding the impact of transition. Many organizations are electing to combine their initiatives for application rationalization and migration to the cloud. IT leaders are forced to accelerate the rollout of new systems and technologies to support the business without compromising the performance of existing applications. They must address key issues, such as balancing cost, complexity, and capacity, and also deliver business value by applying continuous improvement methodologies. Application portfolio rationalization helps organizations turn these challenges into benefits in terms of reduced costs and more value delivered to the business. Application portfolio rationalization is an important and continuous exercise for evaluating and controlling IT costs. Application portfolio rationalization involves focusing on the application portfolio looking for redundant applications, one-off technologies, applications with few users, and applications with a high cost/user ratio. With a complete understanding of the current environment, the next step is to consider what should be done to move from current to the ideal. Gartner Group research confirms that a focused application rationalization effort will typically result in substantial cost savings while improving support for the lines of business. These savings are too large to ignore. Additional...
by John Parker | Jan 31, 2014 | Business Analysis, Uncategorized |
Ask someone about business value and you will most likely get a blank stare or many different answers. Is business value the same thing as Shareholder Value or Customer Value? OK—if all else fails, let’s go to Wikipedia; it is always a trusted source right? Here is the definition of Value in Wikipedia: In management, business value is an informal term that includes all forms of value that determine the health and well-being of the firm in the long run. Business value expands concept of value of the firm beyond economic value (also known as economic profit, economic value added and shareholder value) to include other forms of value such as employee value, customer value, supplier value, channel partner value, alliance partner value, managerial value, and societal value. Wow, I don’t think this helps much. Let’s look at another source. IIBA’s new BABOK (Version 3) that will be published this year is heavily focused on value. IIBA recently conducted a webinar on Value and posted it on YouTube. According to the IIBA and the new BABOK, value is defined as “The importance of something to a Stakeholder in a Context.” I am not sure that I agree with IIBA’s definition of value but I definitely agree with the IIBA when they say “Value is not understood.” At first look, this definition is nebulous, but it has components that are very important. There are three key words here that we have to focus on: Importance, Stakeholder, and Context. Importance – Importance allows us to compare one option to another and make decisions in terms of what delivers the most value....
by John Parker | Jan 29, 2014 | Business Analysis, Uncategorized |
The Standish Group 2013 CHAOS Manifesto Report titled “Think Big Act Small” presents two core concepts to achieve more successful projects. The first key is to break a project down into small independent components that can be managed and delivered separately. The second key is eliminating features that provide little or no business value. Let’s examine both of these. Breaking a Project Down It is important not to confuse breaking down projects as simply defining milestones, phases, critical paths, and activities. These are simply components of a single large project. It literally means breaking a project down into a series of independent smaller projects. Each smaller project is defined, developed, and delivered independently producing a valuable result. The Standish Group says “A large project has virtually no chance of coming in on time, on budget, and within scope, which is The Standish Group definition of a successful project.” The Standish Group reports that large projects are 10 times more likely to fail, meaning the project will be canceled or will not be used because it outlived its useful life prior to implementation. In contrast, small projects have more than a 70% chance of success. Breaking down a large project into a series of smaller projects does not require migrating to agile, although use of the agile methodology can help in this regard. Breaking one large project into five or ten smaller projects and delivering each one independently can greatly improve the likelihood of overall success. Breaking down a project is not always easy, but can be done. The writers of this CHAOS Manifesto Report state flatly that they have come...
by John Parker | Jan 27, 2014 | Agile, Uncategorized |
The term Dual-Track Scrum, invented by Jeff Patton, independent Agile Coach from AgileProductDesign.com, represents an approach to software development that assumes that there are two key tracks for agile product development: Discovery and Delivery, as shown in the diagram below: This approach has a lot of merit and can eliminate a lot of frustration and costs in agile development. Often, agile teams have long and frustrating sprint planning meetings because backlog items are not well defined, understood, or validated. This often results in slow velocity and extra development iterations because a basic understanding and design details are worked out during the sprint using code. The amount of waste and rework is very high because backlog items have not been defined and validated properly. To get around this, some agile coaches have recommended that teams spend 10% of their time grooming the backlog. Some agile coaches even recommend conducting separate meetings for grooming, sometimes referred to as “Story Time” sessions, for the sole purpose of grooming the backlog. An agile project, like other projects, is subject to “scope creep” in the form of user stories that get created but do not really yield substantial value , yet were thought to be “good ideas at the time.” Another problem is that teams and often product owners are not qualified to assess business value and validate ideas for need. A much better method to prevent these problems is to implement a dual track for discovery and delivery. I firmly believe this dual-track approach will increase velocity, provide higher quality products, and at a much lower costs. The discovery track is all about...
