PoddarCo

We practiced a technique to write user stories that is worth sharing. Some of the ideas are similar to those mentioned in “The Art of Writing Use Cases”.

To get to a good user story, the following template was suggested:

AS A ___________ (leads you to think from a user perspective, identify multiple user profiles, etc.)
I WANT TO ___________ (leads to the required functionality)
SO THAT __________ (leads to the business value, desired outcome)

NEXT, layer this user story with specific ACCEPTANCE CRITERIA (the acronym SMART or INVEST may ring a bell). The acceptance criteria guide development, unit testing and writing of detailed use cases as well as test cases.

Illustrating this point with a simplified example from an actual project -
AS A story editor
I WANT TO be able to quickly search through multiple stories and filter them based on whether they are published, in-progress, internal documents, part of my contents or part of my workgroups
SO THAT I can focus more time on editing and reviewing the story rather than locating it

AC-1: Search results should load within 5 seconds
AC-2: Should be able to select multiple filters, example – published and my contents
AC-3: Search and Filters should be easily accessible as options from any screen on the application
AC-4…etc…

This approach communicates the big picture and acceptance criteria which may prove useful when working with virtual teams. However, writing these stories is only the starting point in requirements capture, and can be fairly time consuming depending on the needs of a project. It is even more helpful if you start assigning story points but talking about that would take this blog entry on a tangent, hence shutting up now…

Just sharing a presentation I did at the Talener group. This presentation highlights some of the challenges with requirements capture processes, proposes a requirements life cycle / framework for better management, ownership and tracking of requirements and describes what constitutes a high quality requirement. The key takeaways are driven home through a simple yet effective pasta salad illustration.

A few weeks back I posted a requirements management life cycle.  Since then many of you sent very valuable feedback.  I updated the previous diagram to reflect a more iterative and collaborative approach, especially during the Requirements Identification phase.   I also highlighted how requirements feed into other processes such as Estimating and Release Management (these processes are not addressed in this post or the white paper but stated for completeness).

Requirements Life Cycle - Updated

.

For more details on this click here to download the white paper

(On the homepage, click speech bubble next to the title to leave comments. On the post page, scroll down)

A new white paper titled, “A Project Manager’s Perspective: The Importance of Early and Thorough Requirements Capture” has been uploaded to PMI and PoddarCo.

To download the paper, please click the White Papers link on the top right corner of the screen.  If you are a PMI member, you can also find the white paper under Resources – Knowledge Shelf – Requirements Management.

Brief synopsis of the white paper:
The aim of this paper is to share a project managerial perspective on requirements capture. This paper proposes a requirements life cycle (framework) for better requirements ownership and management throughout a project. It highlights the iterative nature of requirements, calls out some of the basic misconceptions and suggests areas for risk identification (as related to requirements).

The key takeaways are driven home through a simple yet effective pasta salad illustration. The paper also includes some effective tools you can use instantly: 7 criteria for a high quality requirement, checklist of 7 potential sources of risk within requirements, a sample requirements traceability matrix and 7 simple lessons for better requirements capture and management.

Hope you find this material helpful and practical.  I would love to hear your feedback.  So please feel free to reach out to me via comments on this blog or via email at varunpoddar@poddarco.com

Regards
-V

(On the homepage, click speech bubble next to the title to leave comments. On the post page, scroll down)

*Please note that the Requirements Life Cycle has been updated since it was originally posted here.  Please see http://www.poddarco.com/2009/07/02/requirements-life-cycle-updated/ for the latest updates.

The following is an excerpt from my next white paper on requirements.  I am trying to tie the various forms that requirements take, essentially trying to put a frame around them and bucket them in distinct phases. Thought I’d share the idea and get some feedback.

- – - Excerpt from ‘A Project Manager’s Perspective: the Importance of Early & Thorough Requirements Capture’ – - -

Requirements start out as customer or stakeholder wish lists. Wish list entries may be itemized into business requirements. Subsequently, business requirements are further defined as user stories and functional requirements, which answer the questions what, when, why, and where. Ideally, the development team will conduct feasibility studies to ensure that requirements can be satisfied. If necessary, a prototype should be produced and use cases should be developed; these should be verified with a group of users. This helps capture suggestions and allows revisions to be made earlier in the process, avoiding rework and resource wastage. It also enables the team to get preliminary end-customer validation and ensure that stakeholder expectations are being met.

Thereafter, the development team generally produces a technical requirements document, which answers the questions how and who, while reaffirming what, when, why, and where. Together, the functional requirement and technical requirement documents form the basis for testing and quality assurance. They can be used to set up test cases, end-user help guides, as well as help-desk support documents. The higher the quality of defining and clarifying requirements up-front, the better the downstream documentation, finished product, and end-user experience.

The figure below ties a project managerial perspective of the requirements life cycle to the phases described by Kusiak and Tang (2006).

Requirements Life Cycle

Kusiak and Tang (2006) describe the requirements life cycle as having three phases: requirements identification, requirements diffusion, and requirements attainment. They also highlight a very important characteristic of requirements: the evolutionary nature of requirements—that is, that a requirement may change its form, merge with other requirements, or be eliminated. The first phase of the requirements life cycle, requirements identification, is the process of capturing customer requirements using methods such as interviews, focus groups, and observation techniques. Requirements diffusion entails conversion of ambiguous customer requirements into more detailed technical requirements. The last phase of the requirements life cycle, requirements attainment, is the process of verifying that requirements have been incorporated into the final product. As stated, the figure above ties a project managerial perspective of the requirements life cycle to the phases described by Kusiak and Tang.

References:
Kusiak, A., & Tang, C. Y. (2006). Innovation in a requirement life cycle framework. Proceedings of the 5^th International Symposium on Intelligent Manufacturing Systems, IMS ‘2006, Sakarya University, Sakarya, Turkey, pp. 61-67.

(On the homepage, click speech bubble next to the title to leave comments. On the post page, scroll down)

The title of this post was changed to “Where can you look for risks” to highlight an important point raised by Ricardo Guerreiro in a linked-in comment: risk identification is a collaborative process involving all team members. The earlier title could be misinterpreted as suggesting the PM should identify risks. Usually brainstorming works well for risk identification. A good place to start with is the set of requirements.

Looking for Risks?

For all requirements, list systems to be touched, applications or functional areas affected and stakeholders who requested the requirement.  Then, group the requirements across each category and prioritize them.  Look out for conflicting requirements from multiple stakeholders – this should alert the team to a potential political risk.  Look for interfaces needed with other applications or systems – this should alert the team to potential integration, timeline, resource and cost risks.  Similarly read across the requirements and between the lines to identify more risks.

Here are some other suggested areas to look into - 

• Licensing – are there any restrictions on usage of reference materials? Does any requirement mandate use of software that needs licensing agreements between vendors and suppliers?
• Legal, copyright and other notices – do any of the requirements call for legal disclaimers, warranties, copyright notices, patent notices, trademarks or logo compliance issues?
• Security, confidentiality or other standards – is there any data sensitivity or information sensitivity risk?  Are there any corporate standards or government-mandated standards to be aware of (Examples: ISO standards, Sarbanes-Oxley compliance, PMO guidelines)?
• Internationalization and broader application – can any requirement apply outside the immediate business vertical or functional area?  Does any requirement span a different geographic area or demographic?  Making a simple functionality accessible to someone in another corner of the world, or in a different language, can significantly alter the end-design and stretch project resources.
• Performance and scalability – can any requirement create performance issues, either from a user or system perspective?  Do any requirements lead to capacity or scalability concerns (Examples: load, storage, response time or efficiency)?
• Culture – can any requirement lead to a significant organizational or cultural change?  If so, executive sponsorship and proper change management will be instrumental to its acceptance and success.
• Training – can any requirement create more complicated training needs?  Will training be online or onsite, for how many users at a time and for how many users in total?

Click here to leave a comment (or click the speech bubble next to the title)