Business Analysis and Project Management Trends in 2014

Normally, trends and projections come out in December or January.  These are a little late, but at least they still make the first quarter in 2014.  Here are my predictions of key trends that we will see affect business analysis and project management in 2014. 1. Agile Continues to Grow – Agile adoption will continue to grow.  This will mean many changes in terms of how requirements are developed and managed. Requirement “shall” statements will be replaced with user stories. The three C’s model of users stories: Card, Confirmation, and Conversations will continue to grow. PMs and BAs will continue to redefine their roles in the agile world of self-managing teams and product backlogs. 2. Managing Data not Documents – As agile adoption continues, the need for large paper based requirement documents will go away. Requirements will be managed as data in a backlog, not as long paper-based business requirement documents (BRDs) or Functional Requirement Specifications (FRS). 3. Dual-Track Agile Takes Off – Agile will be difficult and a cultural challenge for many organizations where there are multiple teams and resources are not collocated. “User story hell” will become a reality for many organizations as teams continue to spend more and more time grooming the backlog. Many organizations will adopt dual-track agile or some variant to better manage discovery activities.  This will enable lower costs as requirements will be validated using less expensive methods than code. 4. More Emphasis on Business Change – The BABOK Version 3 will be released sometime in 2014.  There are big changes coming to the role of business analysis. The focus will be much...

The Three C’s of User Stories

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:...