How you define a feature impacts your agile mindset and may impact the culture and collaboration you are trying to achieve.

Following up from my recent article on InfoWorld on 5 tips on configuring Jira for multiple teams, I thought to describe some of the antipatterns in defining features and some best practices.

Let’s first look at the antipatterns.

What a Feature Isn’t

Epics should be themes that are relevant across multiple releases, and projects should be configured with a manageable number of active epics. Stakeholders should be able to review the backlog efficiently, and that can be done best with between five and 12 epics. Anything less and the epics may be overloaded with too many user stories, whereas creating too many epics requires more work scanning and scrolling to digest the project. Also, when epics are meaningful across several releases and months of development activity, reporting around epics is a lot more useful.

Most applications have too many features and creating them as epics in Jira would just make using the tool cumbersome.

So What is a Feature?

I like features to represent the following:

(i) The smallest unit of interactions a customer or user can do with your application that provides
meaningful value.

(ii) A feature is something that the product owner can use in marketing to customers or users around something new or enhanced around the product or application.

(iii) A feature should be able to be developed, and later on maintained in one application release.

Principle (i) (ii) insure that the feature is both describable to customers and delivers incremental business value. (iii) and the language in (i) that a feature is the “smallest unit”  and isn’t too big that the development team can’t implement it in whatever size or duration releases done by the team.

Example of an Epic, Features, and Stories

My classic example of an epic is “Enable user access” which focuses on all the registration, authentication, authorization and entitlements for granting users access to a website. This epic likely has several features including (i) registration, (ii) login, and (iii) user administration. Under (i) registration I might have a number of stories for (a) new registration by form entry, (b) registration through a social media account, or (c) registration through the corporate active directory to allow access by employees. For (ii) login I might have one or more stories to support (i) simple username/password, (ii) two factor authentication login, and (iii) forget password workflow.

Now you can debate how I organized the epic, features, and many stories that come out of this structure but it likely does follow the principles I’ve suggested.

Why Provide Guidelines that Define a Feature?

Driving Digital by Isaac Sacolick

Guidelines provide common ways teams and people work together. With epics, features, and stories defined as well as some of the underlying roles and responsibilities you have a better chance of collaboration between the product owner and the team. Chapter 2 of my book, Driving Digital: The Leader’s Guide to Business Transformation Through Technology has a lot more around agile practices, roles/responsibilities, and culture.
Also, with these guidelines in place you now have a working standard that can be applied across teams. These definitions don’t box teams into a single way of working, ie they are still self-organizing, but they do provide a common language and approach to managing requirements.

Lastly, with these definitions in place you can start putting some key performance indicators in place. I like looking at new and enhanced features delivered by quarter as a way of measuring and communicating a team’s success.