Features vs Stories

By Tim Ackroyd on

 I talk about "requirements" quite a bit through out my delivery journeys. Each time we start a delivery effort (large or small), I cringe around what is coming next. And that is the frustration in getting requirements of any kind out of the stakeholders.

NOTHING SEEMS TO BE AGILE!!

Agile is not agile and SAFe is now safe.

In 1986, Dr. Barry Boehm (May 16, 1935 - August 20, 2022), whom I referred to as "The Number 1 American Software Engineer" showed me the Spiral Model. He also taught me how to construct software using COCOMO. This is all I needed, I thought then, to effectively assess system and software projects. In fact, I used this thinking to assess any project (construction, manufacturing, and software). However, around 1993, I learned from Kent Beck's eXtreme Programming (XP) User Stories that now I had the best way to elicit and develop requirements.

Then came the Agile Manifesto around 2001 and the hype curve went crazy and all sorts of people came out to jump on the band-wagon and the notion of "agile delivery" has been wild ever since.

Themes? Epics? Capabilities? Features? User Stories? If you ask 10 people what these things are, you will get 25 different answers. This is why no-one seems to deliver anything on time, on budget, or performant. We still spend 80% of the duration of an effort (project, program increment, sprint), leaving 20% of the time having developers creating miracles.

I delivered systems and software at a fraction of what others did, and then asked how I did IT. My answer was, "I got you all out of our way!".

So here I want to focus on Features versus Stories. But first, let's understand Themes and Epics.

Themes and epics are used to group user stories to bigger feature sets, that make sense on their own. From a more semantic point of view: feature is a part of the system you are trying to build, and user story is a way to describe that Feature(s). A "feature" obviously refers to functionality.

I tell my teams that scope (requirements, stories) are broken down by nouns and verbs where a noun are your actors and data, and verbs are your functions.

Essentially, a feature is a group of stories that are related to deliver a package of functionality that end users would generally expect to get all at once. For instance, inline table resizing is a feature that you may find in MS Word or other platforms. In the first pass, we would probably have a single story for inline resizing of tables, but it may be too complex to estimate. So we may break it down into three stories, resize columns, resize rows, and resize the table itself.

Feature and user story as synonyms in a lot of contexts ("I'm working on this story" vs. "I'm working on this feature"). If we look at a User Story as being "Actor, Action, and Achievement", one could say there is a 1:1 relationship between a Feature and a User Story.

If we struggle on what a "Requirement" is (e.g. Business, Functional, Non-Functional, Security, etc.) and we struggle on what a Feature is versus what a "Story" is, then we will continue to struggle in delivering anything.

I will continue to talk more about this in my Channel, UML Operator, around the ideas of Model Driven Development (MDD), Model Driven Architecture (MDA), and Feature Driven Delivery (FDD).

Comments

Post a Comment

Popular posts from this blog

Sparx EA and Open Collaboration

By Tim Ackroyd on
I get asked, quite often, "Is there a way to integrate Sparx Enterprise Architect (EA) with other tooling?" My answer is always, "Yes". There are multiple approaches, from very simple to more advanced. I have helped several shops do this over the years, and may do videos on this in the future. Integrating Sparx with Azure DevOps and other Cloud platforms, as well as other Tooling, is very possible and beneficial for managing delivery, such as requirements, problem solving, design, and development... all in a unified way.  The integration can allow companies/shops to seamlessly synchronize between Sparx EA's modeling environment and platforms, such as Azure DevOps'. Remember that one of the biggest benefits of Sparx EA over other modeling platforms, is that Sparx is based on Data-First implementation and supports open integration. Years ago, something call Open Services for Lifecycle Collaboration (OSLC) came out and Sparx was one of the first to embrace it. ...
Read more

BPMN Diagram versus Sequence Diagram

By Tim Ackroyd on
I am getting some great questions in our  UML Operator Channel , as we are publishing  a series on Business Process Modeling Notation (BPMN) . Modelers see the term "Sequence" in BPMN and get a little confused...probably my fault 😏. When using BPMN, just understand the difference between Unified Modeling Language (UML) and BPMN (an extension of UML) and things should fall into place. So now let's talk about BPMN vs UML Sequence Diagrams... BPMN Diagram versus Sequence Diagram BPMN diagrams and sequence diagrams are both types of visual representations used in the field of business process modeling and software engineering, respectively. While they share some similarities, they serve different purposes and focus on different aspects of a system or process. BPMN Diagram: Purpose: BPMN (Business Process Model and Notation) is used for modeling and documenting business processes. It provides a standardized way to r...
Read more

MDA vs MDD

By Tim Ackroyd on
This post kicks of a new series on UML Operator Channel  UML Operator Channel around systems and software delivery, titled "Model-Driven Anything". Subscribe, turn on notifications, follow, and most importantly...Contribute 😎 IMPORTANT NOTE: Never start a software development effort without Requirements!!! or Scope!!! However, sometimes software starts out as a means of developing scope and requirements! So what are we talking about? Model-Driven Architecture (MDA) and Model-Driven Development (MDD) are both approaches within the realm of software development that emphasize the use of models as primary artifacts in the software engineering process. However, they have distinct focuses and methodologies. Here are the key differences between the two: Model-Driven Architecture (MDA) Origin and Standardization: Origin: MDA is a software design approach proposed by the Object Management Group (OMG). Standardization: It is a well-defined framework with standardized guidelines and...
Read more