RequirementCoach Analyst Brief

How to Deliver More Business Value in Less Time:

Twelve Ideas for Business Analysts
Almost every organization is under increasing pressure to deliver more, in less time, and at a lower cost. This goal of agile development has been very successful in many organizations. Whether or not your organization has adopted agile, here are twelve innovative ideas you may want to consider to deliver more value in less time. 1.  Use Features: Break your project into features, prioritize the features, and work on the features that deliver the highest value first. This approach will provide many benefits, including developing better requirements, delivering value faster, and eliminating low value functionality that is never really used. 2.  Measure, Measure, and Measure: It is important to start measuring your process if you dont already do so. For starters, record the day when the idea was identified, when it was ready for development, when development started, when development ended, when it went into QA, and when it was deployed. Armed with those numbers, you can calculate your lead-time from idea to going live. You can calculate the duration of your buffers: how long a feature waits before going into development, before going into QA, and waiting for being released. Measuring the time from feature ideation to delivery is essential to shortening lead-times. 3.  Use Features to Promote Parallelism: Different sets of features often require different subject matter experts. For example, take implementing a new HR system; the SMEs for payroll processing are probably very different than the ones involved in recruiting or applicant tracking. Separating the features into feature sets provides the opportunity to work on requirements for multiple features concurrently using multiple SME teams, thereby reducing time from ideation to implementation. 4.  Reusability: Reusing requirements can save significant amounts of time. For example, it is best to define nonfunctional requirements early as a separate feature and then reuse these across all other features. There are many other areas where requirements can be reused, thus increasing efficiency and reducing cycle time.

Copyright 2013 Enfocus Solutions Inc. All Rights Reserved

RequirementCoach Analyst Brief 5.  Requirement Bundles: Features are very good for managing business value and for developing requirements. However, features may not be the best way to build the system. Delivering requirements to development in bundles (i.e., groups of requirements organized by development iteration) provides opportunities for rapid development and for building and maintaining momentum. As depicted below, managing features helps control the input to the backlog while managing bundles helps control the output for implementation.

Feature Requirements Backlog Feature

Bundle

Feature

Bundle

Bundle

6. D  eliver Requirements Electronically, not via Paper: Many organizations still use Microsoft Word to create requirements and produce large paper requirement documents. Trying to maintain different versions of these documents and providing all related details can be a real nightmare. Moving to electronic capture, tracking, and delivery of requirements can save a great deal of time and allow all information about the requirement, such as change history, conversations, visualizations, and related business rules, to be made available. Reproducing a new requirements document every time a small change is made to a requirement does not work well in todays environment. 7.  Validate and Review Requirements Collaboratively: Requirements should be reviewed and validated as they are developed rather than waiting and validating all of them in a large paper requirements document. Using a requirements collaboration tool such as Enfocus Requirements Suite (http://www.EnfocusSolutions.com) will shorten the cycle time for review and validation of requirements. Catching requirements early can save time, produce much better requirements, and lead to a more satisfied user community.

Copyright 2013 Enfocus Solutions Inc. All Rights Reserved

RequirementCoach Analyst Brief 8.  Deliver Requirements Just-in-Time and at the Right Level of Detail: The level of detail needed for requirements is a tough question the answer to which will vary based on number of issues, such as: a. Is development outsourced? b. How much access will developers have to SMEs during development, if any? c. How much domain knowledge do the developers have? 8.  Developing requirements at the right level of detail is important. Too much detail is expensive and can sometimes be confusing to developers. Too little detail will result in developers making assumptions, being wrong, and under-delivering on functionality, causing rework and/or delays, as well as leading to dissatisfied users. To minimize this risk, the level of detail should be agreed up front. Developers should be asked to review initial requirements to ensure that they are at the level of detail need for development. Retrospectives should be conducted after each requirement bundle is delivered to development to determine if it is necessary to adjust the level of detail in requirements that is needed to support the project. 9. C  onduct Requirement Retrospectives: Requirements should be delivered incrementally to development in requirement bundles. After each requirement bundle has been delivered, a retrospective should be conducted to identify what worked well and what needed improvement. Retrospectives are used in agile development, but they are seldom, if ever, used for requirements development. Continually making adjustments to requirements development processes helps significantly in producing excellent requirements at the right level of detail and eliminating waste from the process. 10.  Eliminate Unnecessary Functionality: As studies have shown, the 80/20 rule holds true for software development. With 20% of development, you will satisfy 80% of your customer needs. Its important to identify the 20% of your requirements that provide 80% of the value. Shorten the list of features or requirements to the 20% that provide most value and your lead-time for features will be dramatically reduced (in an optimal case, by 5 times). Also, keep in mind that studies have shown that as many as 64% of features are never or rarely used. Those features clog your development pipeline, increase lead-time for all other features, and arent used by your users!

Copyright 2013 Enfocus Solutions Inc. All Rights Reserved

RequirementCoach Analyst Brief 11. F  requent Releases: The biggest buffer is often the release buffer, so well talk about that one before all other buffers. If you have a 6 month release cycle, most of your features will be developed, tested, and begin providing value, but will need to wait several months to be released. You should consider shortening your release cycle to 2 or 3 months. Then, if youre comfortable with this, shorten it to a monthly cycle. 12.  Eliminate or Shorten meetings: One big waste that prevents developers from developing code is meetings. Developers can get much more done when they concentrate on developing code by limiting the number of meetings they attend. A collaborative requirements tool can help eliminate many meetings. Developers can request clarification and additional information via collaboration rather than attending meetings. Let your developers write code and work on customer value. Taking a look at Scrum will help. Scrum as an agile methodology has a pre-defined set of meetings, all with actionable and time boxed results. This minimizes the number of meetings conducted that seem to go on endlessly without clear results.

Copyright 2013 Enfocus Solutions Inc. All Rights Reserved