Agile Methods

A Feature Tree is an RML Objectives model that shows the full scope of features for a project or product on a single page in a tree format. A feature is just a short form description of functionality provided by the project or product that brings value to the end user. The Feature Tree is great for bringing new people on a project up to speed and showing executives, business stakeholders, or customers all the features that are in scope for a project or release.

Process Flows are usually used for user facing projects/systems, although their cousin, the System Flow, can be used in virtually the same manner to document system processes and logic.  When on an agile project, the Product Owner (PO) or Business Analyst (BA) will usually elicit the high level process flow (L1) in a sprint 0 or planning type phase. From there, during that same planning type phase, the L2 processes to be created will be prioritized and the PO or BA will usually work on the 1-2 highest priority process flows at the L2 level. This is to build the initial backlog.

With the rise in popularity of agile methods, business analysts and product owners often use the term “agile requirements” to label their work.  We do not care for the term “agile requirements” because it implies that the requirements for an agile project are somehow qualitatively different from those for projects following other life cycles. A developer needs to know the same information to be able to correctly implement the right functionality regardless of the life cycle being used.

Sequential Development is the traditional approach that allows the business analyst to perform business analysis during the initial phases of a business process. The novelty brought by Agile was that it challenged practitioners to perform business analysis throughout the entire development process. This is a fundamental difference between Agile and Sequential Development because Agile recommends the continual re-evaluation of the initial business analysis. The present article will discuss business analysis in Agile by focusing on Scrum implementation.

The Agile Manifesto was born out of frustration by a group of developers who were fed up with how software was being developed. Software development is a learning experience and no one understands this better than those who are actually writing the code. Waterfall was a misguided concept that seems reasonable on the surface but does not work in reality. Since software development is a learning process it is impossible to think of every single requirement up front and have them signed in blood before starting development.

This article extends design thinking into a process and method that uses a range of common Business Analysis techniques to drive engagement through collaboration. It provides more structure to either side of the creative process to one better frame the domain of concern, and secondly after creativity has produced ideas, to prototype, refine, test and learn. The article also positions this process as a better way to arrive at a business case or pre-project phase, since it provides enormous insights through an engaging discovery process; something that would never occur within a traditional environment into investigation investment feasibility.

Agile, formally introduced in 2001 through the Agile Manifesto, has morphed into many variations and been customized within organizational cultures and projects. After 14 years since its introduction, this article raises an important question.

A product roadmap is a powerful tool to describe how a product is likely to grow, to align the stakeholders, and to acquire a budget for the product. But creating an effective roadmap is not easy particularly in an agile context where changes occur frequently and unexpectedly. This post helps you create an effective agile product roadmap using my roadmap format, the GO product roadmap.

If you are a Scrum Master of an agile team, your prime purpose is to help the software development team remove obstacles that are impeding progress. The best practice approach in succeeding at this is to assume the role of a neutral facilitator. That is, the Scrum Master guides the team through a process for solving situations themselves rather than the Scrum Master proposing a solution. This article provides two workshop scenario exercises (an internal team conflict and a team conflict with the product owner) that help the Scrum Master practice the neutral facilitator role.

During a recent project where we were adopting aspects of Agile into a very waterfall environment I found myself repeatedly verbalising the concept of ‘definition of done’ to project owners and sponsors. This explanation was met with satisfied faces from people who loved the concept. This lead me to think how this seemed to be a revolutionary concept where it is something that I live by and strive to do everyday.

Creating a product with a great user experience requires more than just user stories. While capturing the product functionality is important, the user journeys, the visual design, and the nonfunctional properties have to be described too. Stories should be complemented with other techniques including scenarios, storyboards, and design sketches.

The 3 Amigos (sometimes referred to as a “Specification Workshop”) is a meeting where the Business Analyst presents requirements and test scenarios (collectively called a “feature”) for review by a member of the development team and a member of the quality assurance team.

User stories are probably the most popular agile technique to capture product functionality: Working with user stories is easy. But writing good stories can be hard. The following ten tips help you create good stories.

In the past few years, software development has been shifting more and more from traditional to agile practices. This change impacts how business analysts perform their role. Here are three key aspects of the business analysis work that are different in an agile environment

Tracking project status means comparing where you really are at a particular time against the expectation of what “complete” means for this development cycle.  Monitor the status of just those functional requirements that were committed for the current release, because that’s the set that’s supposed to be 100 percent done before you declare success and ship the release.