User Story vs Deliverable
I work in the banking sector and we have started transitioning to scrum using jira. As you can imagine the back end systems are tightly coupled not only internally but also externally with other banks and service providers (like Visa or Mastercard). Our business has asked us to enhance our software such that we can support a new type of functionality (Apologies for being vague with my examples) and we have identified the changes required will take well over a sprint to deliver and test appropriately. As a result we have tried breaking down the larger epic into smaller user stories (e.g. add new fields to a communications interface with a third party, create new calculation logic within the system, create new reports) on the basis that they are individually testable (to an extent) and can be delivered within a sprint.
However one of the things we need to do is test with an external party and prove to them our changes are correct before we are allowed to go into production. The challenge here is that due to interdependencies and the nature of their testing requirements, the stories can't be tested independently. Does that mean that from a story perspective we are unable to close any of the stories until essentially the last one is delivered and we are able to test them all together? Or is there another way to capture this extra testing effort separately?
Since participation from the external party is needed in order for work to be of release quality, they will effectively contribute to the membership of the Development Team.
Is this understood by them and by the wider organization? If so, how do they propose to change their working practices (e.g. testing requirements) so a “Done” increment will in fact be built each and every Sprint?
Can the increment you created in a Sprint be potentially releasable without the outside testing? If not, go back to what @Ian said because that is what you will need to resolve.
If you can be potentially releasable in a sprint without the outside testing, then that is what you do. The outside testing can be done outside sprint boundaries and any issues found introduced into product backlog, ordered appropriately to be addressed.
Notice the emphasis of potentially. There is nothing in Scrum that says you have to release every sprint. It just says that there is the potential to release. It is up to the Product Owner to decide when the sum of your potentially releasable increments are finally released.
Thanks for the comments.
Ian, to add some clarity, the external party is Visa itself and as you can imagine when dealing with companies the size of Visa (and the amounts of compliance/regulatory controls in place) they are completely prescriptive in the way they perform certification. If we as a financial institution want to interact with Visa then we play by their rules. Will they potentially change the way they go about certification in the future to cater for agile methodologies? Potentially but such an initiative would have to come from far far bigger players in the industry than my company.
Daniel, in regards to taking it outside the sprint boundaries, I feel I will face significant push back, as they see jira as a place where they can see everything in one go. While I fully appreciate this is not really a scrum problem but rather a management problem, but given we are very much in a transition period is there a middle ground that could be utilised? Could I potentially raise a task that sits under the epic so that we can successfully close stories within sprints, but still indicate the epic is not complete until the certification task is completed as well?
I really think that you should look into Kanban. It has a lot of components that seem to be a better fit for your organization. It will allow you to track the outside acceptance testing as part of the process and still allow working on multiple "stories" at the same time. It will make things very apparent when something (such as Visa's acceptance testing) is causing work to build up in one place. There is a guide and certification on this site that talks about using Kanban within Scrum (https://www.scrum.org/resources/suggested-reading-professional-scrum-ka…). After you do some study on Kanban itself, look at that page. Read the Scrum with Kanban guide, look at the suggested readings. It is quite possible that you could find the answer you need in that course of study.
Also remember that Scrum is a framework, not a methodology, that can wrap many other agile practices. Many of the agile methodologies will provide more rules/guidance on specific practices that could help you. You probably can find ways to incorporate some of those into your Scrum framework. But I suggest you remain true to the Scrum framework because it will provide you the inspect/adapt opportunities you need to improve.
Will they potentially change the way they go about certification in the future to cater for agile methodologies? Potentially but such an initiative would have to come from far far bigger players in the industry than my company.
I wouldn’t advise attemting a transition to Scrum under these conditions. The benefits are unlikely to accrue, since the team will not be in a position to release “Done” work and to inspect and adapt accordingly.
Establishing a Kanban might be more realistic, in so far as it may help to visualize policies, the accumulation of value, and flow.
Thanks Daniel and Ian for your detailed answers. I will certainly investigate kanban and how the types of projects we do could utilise it.
Really refreshing to hear about different approaches. Sadly within my organisation we have a lot of people who are only interested in taking credit for implementing agile rather than actually making it work and are ironically very rigid in their plans
Sadly within my organisation we have a lot of people who are only interested in taking credit for implementing agile rather than actually making it work and are ironically very rigid in their plans
Welcome to the club!