What is technical spike?
Estimation is the center of agile planning or sprint planning. But you cannot estimate a user story till the time you know the what is the work. For this sometimes you need to put extra efforts to understand business requirement and its technical feasibility. Therefore to understand the business requirement and technical feasibility development team allocates some time and perform some research. Time allocated for these kind of research may vary from 1-2 days. This activity, when you are trying to understand the user story so that you can estimate it, is called technical spike. The objective of technical spike is not to solve the problem or deliver the user story. Mostly output of technical spike is a through-away prototype. If work done during technical spike should be used for development purpose then this kind of technical spike is called Tracer Bullet.
What is user story?
When you are managing project using agile methodology that time you do not have access to complete requirements of users. In fact this is one of the reason you chose to manage project using Agile methodology. Therefore, it does not make sense to spend time and try to understand the complete system requirement, document, baseline those to start your project execution. That is never going to happen. So how to understand requirements?
In this situation User-story comes to our rescue. As a product owner, you need to understand user’s expectations from the new system. These expectations are documented in fixed format without bothering about detail requirements and implementation details. These high level requirement in the form of features are called user stories if they are written in a specific format. A popularly used format to understand customer expectation is “As a ‘user’ I want to do ‘something with system’ so that I can achieve ‘some goal'”. User stories are written from the perspective of user, the way they see the system helping them. Irrespective of technology implementation, they have some objective they want to achieve. User story should help in defining that objective.
Can you give me some examples of user stories?
- As a ATM-user I want to print my withdrawal receipt so that I know balance in my account after the withdrawal
- As an online shopper I want to see all the product available in a category so that I can select a best product for the purchase
- As a training participant I want to know complete course outline so that I can make decision whether I should attend session or not.
These three example I have taken from 3 different domains. If need further help, you can approach me.
What is a good user story?
A good user-story should pass INVEST test.
- E- Estimatable
Independent: For the sake of planning and prioritization, stories should not be dependent on one another. Although it is difficult to achieve but strive for it and there are ways to manage dependent user stories.
Negotiable: User stories are commitment of product owner to the development team that he will explain them when time come. So, the details of user story come out during discussion. Thus, stories should be defined, at any given time, only to the level needed to suit the purposes of estimating and prioritization with respect to the applicable planning horizon.
Valuable: User should drive some benefit from the user story. If there is no benefit then why product owner would like to prioritize this for the development.
Estimatable: Three issues due to which team may not be able to estimate a user story. Lack of domain knowledge, lack of technical knowledge, and story size. Therefore till the time enough research is not done by the team to understand what is the work involved in user story they should not estimate and hence it cannot be part of delivery of any sprint/iteration. To handle this project perform Technical Spike.
Small: A good user story is that work which development team can complete within 1 day to 1 week. In case if work going to take more than 1 week time then you should break complex work into smaller manageable steps and create user story for each step.
Testable: Non-testable stories usually manifest themselves as vague requirements. Such as “As an branch manager I want a module to calculate loan interest quickly”. Quickly cannot be tested. So this is not a good user story.
Hope this helps you writing good user stories for your agile project.