The rapid delivery of value requires Agile teams to perform analysis tasks and activities. In a perfect world, the individual playing the role of Product Owner will be deep in business analysis expertise. If that is not reality then the other team members must be competent in business analysis.

So they are basically part-time product owners. The customer cannot afford to hire full-time trained product owners in maintenance projects. In such cases, the product manager or customer is generally the final authority for approval on any functional or nonfunction requirement, as well as having the final word on technical decision making.

Product backlog refinement helps keep the upcoming backlog items discussed in detail and lined up for future sprints. This will improve the rhythm of the Scrum team, and by the time the team reaches the next sprint planning meeting, information about these items will be clear.

Some Scrum teams are taking on User Stories that are truly not READY for the Sprint! So the question is: what can be done to prevent it? Is there a technique that will prevent this from happening or are these teams doomed to keep repeating their mistakes?

For many, perhaps most, development teams the terms requirement and specification are used interchangeably with no detrimental effect. In everyday development conversations the terms are used synonymously, one is as likely to opt for the "spec" as the "requirements." However it is sometimes useful, and occasionally important, to differentiate between the two terms.

The agile approach to software development has significant impacts on the practice of user-centered design (UCD), including usability evaluation. To better understand the role of iterative usability evaluation during agile development, we recently conducted a study whose focus was the usability evaluation of a personal health–management system. The complexities of healthcare systems require thoughtful and well-structured usability evaluations—especially when the design process occurs within the context of an agile development process.

Some while ago, while thinking of a quick and easy way to demonstrate the power of acceptance criteria, I devised this small activity that explains the concept. The activity is interactive and takes about 20 minutes to complete, including the discussion. All you need are some pens and paper and, for a little more dramatic effect, a flip chart -- but that is not essential.

As a global provider of highly constrained enterprise-level financial services software, with customers doing business in every capital market in the world, we know that one-size-fits-all is nonsense. We know that the outcome is what matters most. In building highly complex systems, we prefer to use more words sometimes to describe a more complex thing, and we value well-written requirements and process flows that bring form and context to the fractured and the abstract. We value results over process. We strive to increase engineering success by sanctioning increased team focus and accountability. We know that change is the reality delta between yesterday and today, and our customers expect us to embrace change to safely transition them into tomorrow. Do what works.

This article provides a checklist of best practices on verifying documented requirements – essentially the “function” of the business requirements document.

The profession has transformed dramatically in the last 17 years. When I broke into the field a trend was taking off where companies had roles dedicated to business analysis work and titles like Business Analyst, Systems Analyst or the more common Business Systems Analyst. These titles were found primarily in IT organizations and companies started seriously thinking about how to train people that performed the sole role of business analysis. There are many reasons that sparked this trend.