Background
We usually have some number of user stories to deliver in each sprint. Often, the user stories were created to our best knowledge about some business values that we are going to deliver. It then gets updated with clearer detail over the time as it turns higher at priority over the time. However it is very often that not all details can be gathered before we started to work on a user story. Very often too, there are some new discoveries as we progressing to complete a user story. These are risks, the risks may be preventing a user story from getting complete. If it prevents the completion of the current user story, how we handle it? Can I have a story extends all the way to the next sprint or couple of sprint?
Manage your new found risks in a user story
In agile, we don't like a large user story that spread well over several sprints without a concrete indication of where we are. This does not manage the risks well. However, if it is a main (big) user story that has several not too large but measurable sub user stories where each of them can be completed either concurrently or independently within a sprint, I believe that is very much acceptable and the way I *think* it should be. This makes the user story, whether the main user story or its sub user stories, more accountable, quantifiable and manageable. It then makes things transparent as to when can I expect certain deliverable based on what we know best now. However, many people would argue that this is in fact a dependency of user story and the dependency management usually needs project planning and that is not agile after all. If you think so, you have mistaken my points I am trying to make here.
Say a developer is going to deliver a user story "A" in this sprint and halfway thru the process, he discovered an impediment, say "A'", that prevents him from getting user story "A" done. He has no additional bandwidth or capacity of getting "A'" done this sprint, so he has discussed with SCRUM Master and it seems nobody has better knowledge than he does to handle it, so what a SCRUM Master would normally do is to get Product Owner into this discussion. If nothing much has changed, what should the Product Owner do to this User Story "A" and the impediment "A'"?
As I would suggest: -
- The Product Owner should split the user story "A" into 2 separate sub user stories, say "A1" and "A2", and ensure it is associating back to the original user story "A".
- Eg. A = A1 + A2
- Then, ensure in user story "A1", it covers what we need to get done initially are covered with some mocking functionality of "A2" in a very high abstraction (Hard coded may be?)
- Eg. A1 = A1' + A''
- A1' => What we supposed to do initially in A, but with a bit changes in abstraction to cater for the coming impediment of A' we discovered during this iteration.
- A'' => Mocking functionality or resolution to impediment A' that we discovered.
Then within this sprint, we can have the developer to complete the user story A1 and moving the user stories A and A2 to next sprint or re-prioritize as it sees fits.
Questions
- Are we not agile?
- No, we are. We still follow "just in time" (as we discovered it) and "just enough" (just the mocking of functionality for now) and "just because" (mocking because we can't handle it now, but later)
- Are we doing project planning in advance to identify the dependency?
- No, we don't. We let it happens naturally without factoring in any additional effort in advance to predict.
- More importantly, do we need to emphasis on Agile to be Agile?
- No, Agile is the thought process of getting things done and SCRUM is a framework to do things in agile. They are like best practices recommended to be followed, however you must only follow the practices if that makes sense to you. Ultimately, it is the principle of being continuously transparent, lean in thinking, ready for changes and managing risks with adaptive sprint planning that eventually driving us to the release we planned that makes sense to the business.
Hints
We need a real worker in Agile and SCRUM and not a philosopher.
