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.