Skip to main content

User Story vs Deliverable

Last post 09:44 am November 23, 2018 by Eugene M
7 replies
11:55 am November 20, 2018

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? 


08:11 pm November 20, 2018

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?

 


10:05 pm November 20, 2018

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. 


12:27 am November 21, 2018

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?


04:19 pm November 21, 2018

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.


05:09 pm November 21, 2018

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.


10:58 am November 22, 2018

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


09:44 am November 23, 2018

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! 

 


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.