About the Features Requests category

Discussion about Built Intelligence features for our platform, how they can be improved or enhanced, and how proposed new features could work. If you find a bug please email support@builtintelligence.com Great feature requests always fit the INVEST set of criteria by Bill Wake:

  • I ndependent – they can be developed in any sequence and changes to one feature don’t affect the others.
  • N egotiable – it’s up for the team to decide how to implement them; there is no rigidly fixed workflow/technology.
  • V aluable – each feature delivers a detached unit of value to end users.
  • E stimable – it’s quite easy to guess how much time the development of a feature will take.
  • S mall – it should go through the whole cycle (designing, coding, testing) during one release cycle eg less than a month.
  • T estable – there should be clear acceptance criteria to check whether a feature is implemented appropriately.

The feature request (somethimes called User Story format) (which is used by the Built Itelligence team as well) is quite plain and short:

As a [type of user], I want [an action] so that [a benefit/a value]

Looks like nothing difficult, huh? Here are a few features requests examples that fit training solution app:

  • As a author , I want to notify overdue students so they finish their courses .
  • As a learner , I want to control what notifications i get on my profile so that I focus on complete the critical courses .
  • As a author , I want to add the courses i offer on my profile so that I can attract more learners .
  • As a learner , I want several available teachers to be displayed so that I can choose the most suitable course option for me .

Sounds quite easy but feature request development isn’t often that simple.

1 Like