Skip to main content

New team trying to figure out if data migration HAS to go in a user story

Last post 01:03 pm June 18, 2018 by Filip Łukaszewski
7 replies
11:04 pm June 14, 2018

Hi there,

I am a part of a new team that is very new to scrum and we are clumsily limping along.



Currently we are creating a new system to replace an old system.  The old system is currently live and it has real time data within it.



The argument is this:



50% of team says: when we create a new user story that has a new UI for the user, then we MUST have real live data in in the user story - thus it is one user story.  Create the UI, create the backend and migrate the data.



The other 50% of the team says: We can create a workable UI that produces value for a user, the data does not necessarily have to be in the user story.  Therefore, Create workable UI is one users story.  Migrating and uploading actual data is a second user story.



An important note is that none of these sprints will be going live.  They DO get accepted by the user, but they do not offer any value to the user until numerous sprints are accomplished.



An example would be a shopping cart.  Checking the flow of how a shopping cart looks and feels would be possible.  But there would be no data within.  (we are not building a shopping cart).

I hope this is clear.  Any feedback would be excellent!

 

 

 


03:58 pm June 15, 2018

What does the Product Owner have to say about what constitutes value to stakeholders?


07:28 pm June 15, 2018

And, what does your Definition of "Done" state about the migrated data?  Is the Increment "potentially" shippable every Sprint?   If your Product Owner decided to release the Increment, would there be additional work needed if the data was not migrated, and would migrating it later cause additional integration effort? 


09:50 pm June 15, 2018

your first 50% is right !

50% of team says: when we create a new user story that has a new UI for the user, then we MUST have real live data in in the user story - thus it is one user story.  Create the UI, create the backend and migrate the data.

Scrum Guide : The heart of Scrum is a Sprint, a time-box of one month or less during which a "Done", useable, and potentially releasable product Increment is created. 

Which definition of the user story satisfies this requirement from Scrum guide? Which one is usable and potentially releasable? The one with empty UI or a carefully crafted VERTICAL SLICE that has all technical layers incorporated into whatever small functionality you are developing that is potentially releasable?

Would you rather wait to now how the UI holds out with real data (technical debt!) later and redo the fix for all the UI whose shortcomings you never discovered because you never tested it with real data? Trust me unless your UI is tested with the real data you never know what design changes you have to make. I am certain that your 50% who proposed the right way to construct a user story (or whatever requirement form you used) is well aware of this.

There are instances where what the team thought were primary keys were not even needed when the real data came in and they had to concatenate two fields to create a unique primary key for their envisioned data structure. A simple change of date format could introduce an UI change.

 


09:54 pm June 15, 2018

The only exception is a POC project, where the you are not developing a working product but a proof of concept so the sponsor can fund the real project. In this case it is obvious what the goal is, a prototype without real data. What is the final intended outcome of your project? 


01:35 am June 16, 2018

I agree with #2 The other 50% of the team says: We can create a workable UI that produces value for a user, the data does not necessarily have to be in the user story.  Therefore, Create workable UI is one users story.  Migrating and uploading actual data is a second user story.

I am a former developer and I have worked in operations to and now a scrum master and I see all sides here. I have had these exact same scenarios and the way I handled it is we were able to find a work around. The workaround was with minimal effort and a minimal data set the team was able to create mock data to display the functionality of a new UI.  If you can do that with a large enough data set that will show the functionality get acceptance, then I'd think you'd be OK.  get the PO's buy in on it 

The data migration the way I see it is a integration task. I know up for debate. 

Since you are not releasing live right away you would have time if it is several sprints to figure out the right time\path\ to get that data migrated. Data Migration is at least to me can be done later.  

We are all of course high level guessing of what we think your PO will except  that's why you see the differing opinions. 

 


02:48 am June 16, 2018

An important note is that none of these sprints will be going live.  They DO get accepted by the user, but they do not offer any value to the user until numerous sprints are accomplished.

Based on the text above I would say that if you are not put the new system "on Live", just do the data migration near the "Go Live" of the system. That because if you migrate the data but do not put the system "on live" you will need to review/migrate the data all over again when you put the system "on live" because the data may be changed since the last time you migrated because the old system still running.

Now if you want to change the strategy and you have a way relase the new features of the new system and you "Go Live" with only that feature to the user/client piece by pice and they will start to use that pice the new system and the other features is running in the old one(the 2 systems coexist ), I go with the option #1, do the data migration in the story, so you can deliver the feature and the data, so thats bring more value to the Client/User and they can start to use thats the new system. The only problem here that sometimes the user don't want to live with 2 system, I know because my team tried to do that one time and the user start to complain that he needed to use 2 system, 2 different front-end and etc, so in that case the tip is to always know the final user expectations.



If you can't do what I say above(The old system coexist with the new one done piece by piece) I agree with #2, so you can deliver the new features in production and only when you had something like a MVP and "Go Live", you do the migration and release to the Client/User the new system features and stops to use the old system.

 


01:03 pm June 18, 2018

How about making a copy of production database and just clearing all sensitive data? Then you could point new UI to that test database and be pretty close to prod (not including actual traffic loads).


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.