Just one suggestion to remove feature dependencies and increase project success: order your backlog and discuss with your customer using "Use Cases", not features.
A "Use Case", "User Goal", or "User Story" is more than a feature. Actually, many features (or tiny parts of features) may be needed to support properly a use case. Therefore, ordering the backlog in terms of features may simply bring no business value because the use case may be broken due to the lack of a tiny part of feature N. Also, using features may difficult the communication with your customer.
For instance, imagine in this blog you have 3 features: 1- login 2- post a rich html article 3- comment a post
Using features you would actually need to implement the login (1) before the post (2) if you wanted authentication on posts... Or at least both. You would also eventually need to explain to your customer why posting without login is bad… Now, does login as a feature makes sense at all without the post? No. So there is no dependency, just a wrongly split set of work items, or features, that creates the “idea” of technical dependencies. The use cases implicit above are 2: 1- post a rich html article 2- comment a post The login feature is more a requirement of the “post a rich html article” use case than a feature. It should never be discussed with the customer independently, but in the context of the post or comment use cases.
Afterwards, when you list the features of your system, you will obviously add an item like “User Secure Authentication”, but that should never be discussed alone as a feature. This is what happens in the case of a must requirement along all or several use cases. There are other scenarios in which you only need part of a feature to actually implement one use case. For instance, let’s dig in the “comment a post” use case. You might have a feature named “Rich html editor”. That is a feature that would allow readers to make rich comments to a post. But the use case that probably matters to your customer is the “comment a post”. If rich comments is a requirement, it will popup in the requirements gathering or feedback sessions. In the end, you might find out a text box was more than enough. The point is, having a feature named “Rich html editor” is of no use to prioritize nor to discuss with your customer, unless you do it in the context of the “comment a post” use case, while you discuss or demo the end-to-end user experience that culminates with the goal: make a comment to a post.
This is difficult to do, but we must never lose sight of the use case, otherwise it will be broken without us even noticing. It also helps focusing the teams in understanding what are the ultimate goals and not divert into great small features while the use case is not complete yet.
I'd also emphasize that only after starting using the *actual* system, will end-users understand what works and what doesn't. I'm not talking about bugs, I'm talking about the overall "user experience").
This way, the delivered system will be quite different from the initially envisioned. But it will be much more business-aligned. This is also why it is so important to deliver soon.
Rodrigo Castelo, I agree with you but features and requirements are becoming more like "Use Cases"/"User Stories".
I always try to gather requirements in the story framework from BDD so I can use an ubiquitous language with my client. I use the one from Dan North which combines the behavior with the business value. http://dannorth.net/introducing-bdd
And I use Cucumber for running acceptance tests: http://cukes.info/
So, by the end of the day, features, requirements, use cases, user stories, acceptance tests are very close to each other.
6 comments:
Great description of what Agile is all about. Nice production work!
This is an awesome introduction video to Agile!
Just one suggestion to remove feature dependencies and increase project success: order your backlog and discuss with your customer using "Use Cases", not features.
A "Use Case", "User Goal", or "User Story" is more than a feature. Actually, many features (or tiny parts of features) may be needed to support properly a use case. Therefore, ordering the backlog in terms of features may simply bring no business value because the use case may be broken due to the lack of a tiny part of feature N. Also, using features may difficult the communication with your customer.
For instance, imagine in this blog you have 3 features:
1- login
2- post a rich html article
3- comment a post
Using features you would actually need to implement the login (1) before the post (2) if you wanted authentication on posts... Or at least both. You would also eventually need to explain to your customer why posting without login is bad… Now, does login as a feature makes sense at all without the post? No. So there is no dependency, just a wrongly split set of work items, or features, that creates the “idea” of technical dependencies. The use cases implicit above are 2:
1- post a rich html article
2- comment a post
The login feature is more a requirement of the “post a rich html article” use case than a feature. It should never be discussed with the customer independently, but in the context of the post or comment use cases.
Afterwards, when you list the features of your system, you will obviously add an item like “User Secure Authentication”, but that should never be discussed alone as a feature. This is what happens in the case of a must requirement along all or several use cases. There are other scenarios in which you only need part of a feature to actually implement one use case.
For instance, let’s dig in the “comment a post” use case. You might have a feature named “Rich html editor”. That is a feature that would allow readers to make rich comments to a post. But the use case that probably matters to your customer is the “comment a post”. If rich comments is a requirement, it will popup in the requirements gathering or feedback sessions. In the end, you might find out a text box was more than enough. The point is, having a feature named “Rich html editor” is of no use to prioritize nor to discuss with your customer, unless you do it in the context of the “comment a post” use case, while you discuss or demo the end-to-end user experience that culminates with the goal: make a comment to a post.
This is difficult to do, but we must never lose sight of the use case, otherwise it will be broken without us even noticing. It also helps focusing the teams in understanding what are the ultimate goals and not divert into great small features while the use case is not complete yet.
Really nice video! agree with Paulo - great production work ;)Are you planning to do more?
Great agile introduction!
I'd also emphasize that only after starting using the *actual* system, will end-users understand what works and what doesn't. I'm not talking about bugs, I'm talking about the overall "user experience").
This way, the delivered system will be quite different from the initially envisioned. But it will be much more business-aligned. This is also why it is so important to deliver soon.
Rodrigo Castelo, I agree with you but features and requirements are becoming more like "Use Cases"/"User Stories".
I always try to gather requirements in the story framework from BDD so I can use an ubiquitous language with my client. I use the one from Dan North which combines the
behavior with the business value.
http://dannorth.net/introducing-bdd
And I use Cucumber for running acceptance tests: http://cukes.info/
So, by the end of the day, features, requirements, use cases, user stories, acceptance tests are very close to each other.
Kutuma: Great work!
Very helpful video! Thank you!
Post a Comment