More Questions About Done Increments
Having read many blogs and forum posts, I still do not see a clear understating of how to meet the criteria for potentially shippable in many cases. I want to help my team with this but honestly, I am not convinced. It's like unicorns. Some say they exist but no one has actually seen one.
Here is the scenario:
This is a data intensive project that is building a dashboard on the IBM Cognos platform. The data is mined from a large data store via ETL processes. Breaking stories down enough to make them valuable while at the same time making them potentially releasable is difficult for the team. The ETL process can take a half a sprint or more if it is completed and stable. If I break it down to something like, create a table, stage data, transform data, and load data to ODS. None of those in and of themselves seem "potentially shippable." What value can the customer get out of a table with no data?
Breaking stories down enough to make them valuable while at the same time making them potentially releasable is difficult for the team
Difficult does not mean impossible, so take it one Sprint at a time.
What hard evidence would the customer like to see, after just one Sprint, that the team is on the right track and that it would be worthwhile continuing? Do they understand that they have this opportunity to learn about what is valuable, and to evaluate empirical outcomes?
Could be a stupid idea, but why not explore other ways? There are no claims (to the best of my knowledge) Scrum is a panacea for all situations, and we shouldn't force it where it wouldn't/doesn't work.
Would it be worth exploring whether Kanban could suit your case?
Would it be worth exploring whether Kanban could suit your case?
Would it change all that much? Isn't Kanban all about having rapid feedback loops?
Some additional details: The team has been sprinting for about nine months. The team is fairly high performing.
Our organization is primarily a Scrum shop but has been piloting Kanban. I think the struggle is bringing together the short sprint lengths, small increments, and a DoD that includes all testing given the nature of the work. One the one hand I can deliver an empty database table but what value does that bring to the customer? Also, being that most of the work is ground up and interconnected, the cost of testing over and over again seems high.
It was just a suggestion, not a definite solution.
I hear where you're coming from but without me actually being in OP's shoes, or having experienced a similar scenario, it looks to me Scrum may not be the right approach; to my mind, Kanban seems better suited under the circumstances:
More Questions About Done Increments
The ETL process can take a half a sprint or more if it is completed and stable. If I break it down to something like, create a table, stage data, transform data, and load data to ODS. None of those in and of themselves seem "potentially shippable."
Since there are no iterations in Kanban, eliminating the timeboxing pressure to reach the "potentially shippable" increments seems worthy of exploration. Quick feedback is surely key factor, but you could reach it differently (rather than a per sprint basis).
Also, being that most of the work is ground up and interconnected, the cost of testing over and over again seems high
It should be noted that automation is basically a pre-requisite to using Scrum. If you are testing manually, you will find it very challenging to adhere to the short feedback situations that Scrum supports.
Regarding the project, can stories be identified that deliver just one data element on the dashboard, and can that be delivered within the sprint time box? Can items be split by data source, or different data types? You suggested an approach where items were split architecturally (or by workflow), and these approaches are difficult at best to craft into an MVP.
An approach that has worked very well for me is to ensure that any item being considered is somehow customer-facing. Begin with that goal in mind, and you may find it easier to work in Scrum.
Good luck.