In the third of my posts tackling this subject I address epic requirements. These are requirements where the minimum marketable feature is too large to complete during a single iteration. Here I present some of the approaches that can be taken in such situations, with the respective pros and cons that I can see or have experienced with these.
Tackle as a single requirement which persists from one iteration to the next
In my early days at RainStor this is the approach that tended to be taken.
Pros
+ Provides continuity through the development process
Cons
- It was difficult to track what had been delivered in each iteration
- The approach doesn't encourage early exposure to testing, whole iterations could be spent on development without any exposure to test or any elaboration or review.
From a test perspective this approach was not working and so, with some consultancy help from Dave Evans at SQS, I worked to replace the requirement based approach being used with a different approach:-
Breaking down large requirements into user stories that deliver customer value
This was not an easy transition. The previously used requirements generally had the appearance of being better defined (although the result usually deviated significantly from that definition). Working with much lighter user stories removed the feeling of false confidence that was provided by these requirements specs and some are still getting used to the lack of up front detail and the need for elaboration discussions to provide specification on the stories. Nevertheless a number of significant benefits were shown.
Pros
+ Smaller chunks of value can be delivered and tested within the iteration
+ Elaboration discussions held at each stage providing greater opportunity to review and change direction
+ It becomes easier to measure progress through stories completed
+ Work not done is highlighted quickly and can be addressed through the creation of further stories
There were still some negatives though
Cons
- Sometimes it was very difficult to create anything that could be exposed as valuable customer functionality within an iteration, particularly if one of the legacy components within the application needed changes to the interfaces.
We have had to amend our approach slightly to deal with these issues.
Breaking down large requirements into user stories that deliver stakeholder value
In most cases the stakeholder can be the customer, however for some situations we consider internal stakeholders to be the ones deriving the value from the story. For exmaple, where changes need to be made to the legacy components in order to add new product features then we would take the approach that the developer using that interface is the stakeholder, much as an external developer who uses our API would be.
Pros
+ Allows internal stakeholder value to be delivered and tested without forcing functionality to be exposed to the customer where it is not feasible
+ Maintains the approach of breaking down into deliverable chunks within the iteration
+ Value can be tested using tests at the appropriate level e.g. unit testing of the delivered components
+ We use the approach to cover initial prototyping, where the value is delivered in a set of acceptance criteria and a workflow that has been discussed, demonstrated and agreed with the customer prior to developing functionality
+ The approach can be extended to deliver other internal value as research, infrastructure work, code maintainability, test hardware provision and other items that relate to internal stakeholders
Cons
- Can be seen as a cop-out on delivering customer value
We are constantly refining the approach, but I am pretty happy with the attitude that is being shown with respect to these large requirements now by the team in general. Greater breakdown and consideration of multiple stakeholders, internal and external, is helping to ensure that we deliver the right value at the right time during large scale 'epic' developments.
Post a Comment