When you are on a project which is about evolving a set of services from an existing application, or building from scratch, there is always a lot of talk on the architecture and service governance aspects.
But if you are a Business Analyst on this piece of work, and you are asked to write stories for these services, you will wonder.. "well how can we showcase just services ?". If you have never done this before, you might even conclude that writing stories without a consumer of the service is not such a good idea. A lot of Agilists might argue that having a services story is a bad user story.
This happens because the fact that "Each Service has business value" does not become very apparent. If you look at Amazon WebServices it becomes immediately evident that each of the services have a set of features which can be sold to customers.
Services are a reality in today's world on the web, and people make money by selling services. A story which builds a service to search a book based on ISBN has business value. It does not need to have a pretty front end consumer for you to write a good user story. A temporary client/UI would be sufficient or maybe even functional tests/specs. It is still a good user story. This essence needs to be spread across the entire team, so that BAs and Devs are on the same page on "Good User Stories" for this kind of project.
Both BAs and QAs have to embrace this along with the developers on the team, and look at ways to apply Agile principles considering this, rather than being dogmatic in their approach towards Agile and SOA.
But if you are a Business Analyst on this piece of work, and you are asked to write stories for these services, you will wonder.. "well how can we showcase just services ?". If you have never done this before, you might even conclude that writing stories without a consumer of the service is not such a good idea. A lot of Agilists might argue that having a services story is a bad user story.
This happens because the fact that "Each Service has business value" does not become very apparent. If you look at Amazon WebServices it becomes immediately evident that each of the services have a set of features which can be sold to customers.
Services are a reality in today's world on the web, and people make money by selling services. A story which builds a service to search a book based on ISBN has business value. It does not need to have a pretty front end consumer for you to write a good user story. A temporary client/UI would be sufficient or maybe even functional tests/specs. It is still a good user story. This essence needs to be spread across the entire team, so that BAs and Devs are on the same page on "Good User Stories" for this kind of project.
Both BAs and QAs have to embrace this along with the developers on the team, and look at ways to apply Agile principles considering this, rather than being dogmatic in their approach towards Agile and SOA.
Excellent post, Anand! Wish BAs understood this concept more easily. Making this arguement to a lot of BAs has been like pulling teeth!
ReplyDelete