Just knowing what a ‘feature’ is for Agile project management devotees is a chore and one of the many things about them that Ryn Melberg helps to clarify on her weekly podcast. To hear The Guardian Podcast with Ryn Melberg, visit her website at www.rynmelberg.com. The program can also be heard on Soundcloud and iTunes.
What Is A Feature?
What seems like such a simple question at first is more complicated than anyone could have ever imagined, according to Ryn. “It’s a loaded question for a loaded term,” Ryn said. “Getting to an accepted definition for features should be a goal for Agilists. The better the feature with the end user focus, and execution, the better the feature. Features should deliver value, expressed all the way through consistently.”
There is a tendency in Agile to refer to attributes as features or even user stories as features. The best features are the most consistent and get from the customers’ conception to the sales floor the quickest. “The feature should be a differentiator that gets from concept to cash in a reasonable amount of time,” Ryn explained.
Epics, User Stories and Features
Learning the difference between epics, user stories and features is more challenging as often times these terms are used interchangeably or because of organizational constraints. “An Epic represents the highest level of planning inside an organization,” Ryn said. “Unfortunately in some organizations the feature is the highest level of planning. I always coach folks not to call ‘Epics’ ‘Features’ because it is confusing and not really what the Agile movement intended.”
Using the ‘time-box’ is one way to differentiate between these terms. “A user story can be completed in a day but no more than two weeks,” Ryn said. “A feature will take two weeks but no more than three months to complete. So if the team can’t agree on the nomenclature, they can use the calendar to mark the differences.”
To Write The Best Features
The most often cited example of how to write a feature is using the ‘shall’ method. “Instead of saying ‘send out the newsletters’ in a feature we would write, ‘the system shall send out the newsletters’,” Ryn described. “Of course the word ‘shall’ is not used very often and may not resonate with people, so substitute the word ‘will’ in its place and that works just as well.” Other pointers for feature writing include not making them too long or loaded down with more detail than needed. “Added details will close down the creative process and will lead to narrower solution possibilities,” Ryn stated. “Focus on the end-user and declare what will happen. But whatever your team decides, be consistent in your approach to writing features. It will yield better features and waste less time.”
To learn more visit www.rynmelberg.com.
13 Nov 2017