The projects will be delivered to real people, real world, and real things. The potential peoples to consider are internal end-user or people in your organization and external end-user or who uses your app in the future.
Identifying the Real Problems – The problems are related to a single user story or even to your entire project. The first thing to do is to establish whether or not the people involved in the project means all of the stakeholders who are affected or affect the problem agree that this is a problem that they want to do something about it. Here is the 4 step process to problem/symptom reduction technique,
Step1: Discuss the potential problem with stakeholders to ensure common understanding and acceptance of the statement.
Step2: For each item on the list, anyone involved in the project does anything about it? If not, it is Out of Scope(OOS) list.
Step3: For each item on your reduced list, does it describe how the problem can be eliminated? So, it is going onto a list called potential solutions or maybe the future requirements.
Step4: For each item on the remaining list, assuming it could be solved, would any other item on the list go away? If yes, then the item that would go away is a Symptom (SYM).
Stakeholders have the rights and responsibilities in the agile environment. They have an engaged team to the completion of epic, be informed on the team’s progress, receive lean or agile training on technical, architectural factors and collaborate with the product owner to the growth of a trusting agile environment.
Understanding Features, Stories, and Tasks: It is another important way to acquire the requirements for developing the software. The feature is the unit of things wants by the customer. It is the simple statement that explicit the client need and describe as,
Features = Action + Object
It also provides additional information such as who will be responsible with that feature, the priority of the feature, the iteration when the feature will develop.
Breakdown Features into Stories: Once we have the features, we can break down into stories. For instance, if you have the feature called “Managing the payment for the tutorials”, there are several user stories such as,
- Paying to the tutorials using a credit card
- Paying to the tutorials using the wire transfer
- Paying the tutorials using invoice from the company.
You can see that the story explains the tutorials in more detail based on several constraint and conditions for customer needs. In agile, the user story has the pattern like,
User Story = As a (role) I want to (action) so that (benefit)
In the previous example, the user story is “As a member, I want to pay for the tutorials using a credit card so that I can join the institution right away”.
The break-down of work is important and it should be done across functional, instead of technical boundaries. The process of breaking down the work improves shared understanding, increase the accuracy of estimation and facilitate the product owner in the prioritization of work. It can be done by these types of strategies,
- By Workflow Steps – What steps does user perform? Can these steps simplify?
- By Business Rules – What rules apply to this story? Are all business rules necessary now?
- Input Options – Which platforms supported? Are all platforms required?
- Data types & Parameters – What data types are supported and relevant? Are all parameters relevant at the moment?
- Operations – What operations does the story entail?
- Test cases – What tests scenarios are used to verify this story? Are all test scenarios are relevant at this moment?
- Roles – Which roles are involved in the story? What can the roles do?
- Optimization – What optimization can we think of (UX/UI)? Are all optimization necessary now?
The dimension that makes use of story valuable is the relevance. It is the product owner’s responsibility to make sure that all the user stories he or she collects are in scope of the project. If we start developing user stories that turn out not to be part of the application or not to be within the authority of the product owner or product manager then we are wasting resources which is anti lean. The user stories, features, test scenarios all of the above targets specific components that define a specific attribute of at least one or more components of the application.
The Task is the lowest unit of work assigned to the agile member. It represents the detail of the user story. For ex, the user story “see the student list”, it has 2 tasks such as showing the student list that already paid for the tutorials and not already paid for the tutorials. Tasks are not only about the activity that contains the development but also other activity such as design, requirements, deployment etc.,
Company Profile: Creative Web Graphic Solutions is a Website design and Web development company provides superior UX/UI for your application and branding services for Business to Business, Business to Consumer, enterprises, Lean start-ups across the world. Please feel free visit our website www.creativewebgraphic.com for more information.