"How to write User Stories in Agile Projects"- I am very sure that this question would have a very different answer from different business analyst, product owners, technical community. Story Card should should follow the INVEST characterstics [ I- Independent, N- Negotiable, V- Valuable, E- Estimatable, S- Small, T- Testable]
You may refer to the following article by Bill Wake where he describes about the details of good Story
http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/
In this post I would give a different perspective of the issues teams faces while writing user stories. Writing User Stories from the Customer's perspective and the usage by Developers is relatively easy in Application Development based projects. But in case of embedded , operating system domain teams face issues of vertically slicing the story card and usage by the development and test team.
In my opinion there are following kind of issues. For each kind of issues, I have tried to provide some solutions:
Issue 1- Lack of enough competency where the Business Analyst can really slice the stories effectively cutting across the multi layer (presentation layer, logic layer, persistance layer etc). In some teams the technical members play the role of Business Analyst. And there is no training given to these members. Sometimes it is default assumed that all the members who are technically very good can write good user stories. There is less authentic references available in industry about writing user stories in each domain. User story writing is specific to the domain. It is important that good training be provided to the members involved in writing user story.
Issue 2- There may be some stories that need some background preparation as Spike Stories so that the solution is ready. These strories can also be said as Infrastructure readiness stories. Sometimes these stories are not ready and team members get the stories which are vertically sliced across the layers. In this case the team faces issues related to the technical solution. The solution to such kind of issue is that anytime before the actual development starts, the Business Analyst or the Technical member need to check if the Spike Stories need to be played before the actual story execution. Accordingly, the actions should be taken.
Issue 3- Team members are very junior or dont have enough expertise. In such case stories may need to contain more details and in some cases, solution artefact. There may be also cases where at implementation level, the key algorithm / solution for the similiar implementation can be generalized. Such cases the Designer and the Technical Person need to provide some technical solution so that the implementation is effectively done. This issue may not be there in teams where there are senior members working or where the team size is small.
The important point is that there is no one stop solution for writing story cards. The requirement documentation process needs to be customized based on the situation and domain. If teams face issues with vertical story slicing then team can taken minimum marketable feature based approach and implement the customer requirements. What best fits to the context need to be taken. Story Card has many advantages: if the stories are vertically sliced, it can be developed faster, it gives an end to end value to the customer, customer can give feedback easily, it also helps in other agile practices like continous integration where, faster feedback can be given. However if teams have there own constraints like complexity of the domain (due to which slicing is very difficult), lack of enough competency etc., team can use Minimum Marketable Feature (MMF) approach. The team that use the feature based approach is also as much as Agile as teams using the story card based approach.
References:
http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/
You may refer to the following article by Bill Wake where he describes about the details of good Story
http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/
In this post I would give a different perspective of the issues teams faces while writing user stories. Writing User Stories from the Customer's perspective and the usage by Developers is relatively easy in Application Development based projects. But in case of embedded , operating system domain teams face issues of vertically slicing the story card and usage by the development and test team.
In my opinion there are following kind of issues. For each kind of issues, I have tried to provide some solutions:
Issue 1- Lack of enough competency where the Business Analyst can really slice the stories effectively cutting across the multi layer (presentation layer, logic layer, persistance layer etc). In some teams the technical members play the role of Business Analyst. And there is no training given to these members. Sometimes it is default assumed that all the members who are technically very good can write good user stories. There is less authentic references available in industry about writing user stories in each domain. User story writing is specific to the domain. It is important that good training be provided to the members involved in writing user story.
Issue 2- There may be some stories that need some background preparation as Spike Stories so that the solution is ready. These strories can also be said as Infrastructure readiness stories. Sometimes these stories are not ready and team members get the stories which are vertically sliced across the layers. In this case the team faces issues related to the technical solution. The solution to such kind of issue is that anytime before the actual development starts, the Business Analyst or the Technical member need to check if the Spike Stories need to be played before the actual story execution. Accordingly, the actions should be taken.
Issue 3- Team members are very junior or dont have enough expertise. In such case stories may need to contain more details and in some cases, solution artefact. There may be also cases where at implementation level, the key algorithm / solution for the similiar implementation can be generalized. Such cases the Designer and the Technical Person need to provide some technical solution so that the implementation is effectively done. This issue may not be there in teams where there are senior members working or where the team size is small.
The important point is that there is no one stop solution for writing story cards. The requirement documentation process needs to be customized based on the situation and domain. If teams face issues with vertical story slicing then team can taken minimum marketable feature based approach and implement the customer requirements. What best fits to the context need to be taken. Story Card has many advantages: if the stories are vertically sliced, it can be developed faster, it gives an end to end value to the customer, customer can give feedback easily, it also helps in other agile practices like continous integration where, faster feedback can be given. However if teams have there own constraints like complexity of the domain (due to which slicing is very difficult), lack of enough competency etc., team can use Minimum Marketable Feature (MMF) approach. The team that use the feature based approach is also as much as Agile as teams using the story card based approach.
References:
http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/
No comments:
Post a Comment