The INVEST Principle in User Story Writing
A simple user story template will look like this: As a <user> I want <feature> so that <value>
User stories, when used, are at the heart of agile projects as they embody the work that is to be done. The project team creates product increments based primarily on the user stories. The product owner, and entire DAD team for that matter, need to learn how to create user stories that meet the needs of the project goals and objectives. User story writing skills unfortunately, can sometimes be difficult, especially for inexperienced agile practitioners. But the good news is that they can be learned over time. The INVEST principle can help shorten the learning curve.
The INVEST principle provides a useful concept for writing a good user story. Let's review the meaning of this acronym:
So how does this work in principle? You can follow this simple steps:
The INVEST scale, represented as 1 - 5 and defined here as:
1 - Definitely not
2 - Not sure
3 - Maybe
4 - Looks like / Kind of
5 - Definitely
As a Customer I want to register for new online account so I can access my information
Assuming a threshold of <18, for example, as a rule that a user story with score of less than 18 points needs to be broken down further to be acceptable. Story 3 with 13 points will need to be broken down further. This threshold is up to the team and will vary based on the project and the team's needs.
While this might appear daunting, I would recommend that the product owner, and not the entire team does this for the project team. Remember! This is different from user story estimating, which is relevant for prioritization and important that everyone on the team gets involved in where possible. INVESTing in good user stories will ensure that you are working on items that adequately target the business need or problem to be solved and definitely help save you time when estimating story sizes as the stories would have been scaled to where they are easier to understand.
1. Add a test
2. Run all the tests with a new feature
3. See new test fails
4. Write code
5. Run all the tests with a new feature
6. See new test passes
7. Refactor code
8. Repeat the steps
TDD = Test-First Design (TFD) + Refactoring
Extreme Programming (XP)
1. Apply Test-First-Design
2. Refactor Code
4. Pair Programming
Benefits of DAD over Scrum :
a. Scrum is focused on only "Construction" phase, but DAD is focused on "Inception", "Construction" and "Transition" phase.
b. Scrum delivery is concentrated on "Working Software", but DAD deliverables gives "Complete Solution".
c. Scrum is prescriptive, but DAD is pragmatic ; so DAD is easily tailored.
d. Scrum is targeted from single team to multiple teams ; but DAD is scalable from single team to enterprise.
e. Scrum is one approach process framework, but DAD Life Cycle is the "Hybrid Framework" which includes, Scrum, XP, Lean, Kanban, Continious Delivery, etc.
This forum will concentrate on knowledge sharing for "Disciplined Agile Delivery" framework and fundamentals/foundations of DAD.
© 2014-2018 Disciplined Agile Consortium
600 Crowfoot Crescent NW, Suite 340
Calgary, Alberta, CANADA T3A 5A2