Skip to main content

Data Base Design / Model

Last post 07:07 pm January 24, 2020 by Daniel Wilhite
8 replies
12:32 pm January 5, 2017

I am new to this scrum.. just wanted to know

Who will be doing the Data Base model / design for a product to be developed. In case if any technical / workflow change required in between how it is going to be handled. Is Database model will be done completely before start the actual sprint planning.

Thanks in advance
Regards
Senthil


10:37 am January 6, 2017


Based upon your understanding who is responsible for delivering the Product Increment? The idea is to build a cross-functional team that can do whatever is required for releasing a product increment.

Whomsoever has developed it should make the changes too.

Why should we start anything until and unless it has been prioritized, ordered and discussed during the Sprint? What if during the Work start and Sprint planning something change and the DB model or feature is not required at all?


11:35 am January 6, 2017

Thanks Sanjay

My questions are

1.Is data base model should be completed for product before sprint starts?. Is it going to be reviewed by Product owner and do we need to get any approval from client?.

2.In case during the sprint planning if we need to change the DB model due to feedback from client. how do you accommodate ?

3.We might be delivered working model from few sprints and due to db model change request - existing sprint output might be useless. how do we handle it ?


03:59 am January 8, 2017

Welcome to Scum, Senthilkumar. What was a failure of classic software development? Too much large planning and design up front. In order to be flexible in the creation and delivery of software, only what needs to be designed, developed, tested, and delivered should be done just in time. "Development Teams are cross-functional, with all of the skills as a team necessary to create a product Increment" means that they should be able to identify and implement any necessary changes.

Is the team in question specifically a "database team" delivering to other software development teams? If so, then the larger picture of Scrum Teams being devoted to products is being missed.


04:10 am January 9, 2017


In addition to what Alan said, to be more specific to your questions -

1. NO. Team should work on the DB model for items planned for the Sprint and team forecast the items (PBIs) during the Sprint Planning only. A good PO should focus on the WHAT and Maximizing the Business Value and let the Dev Team decides on the HOW part. Approval from client - it depends on your relationship, trust and contractual T&C between you and your client

2. Any work that needs to be done in a Sprint should come thru Product Backlog. PO should consolidate everything in the Product Backlog, get it refined with the Dev Team and then the Team should forecast the Sprint work, it happens in the Sprint Planning meeting only.

3. If the Sprint goal becomes obsolete then PO can cancel the Sprint. Scrum team should get into the planning meeting of new Sprint along with new learning and updated Product Backlog

Hope this helps


09:45 am January 9, 2017

Thank you Alan


09:46 am January 9, 2017

Thank you Sanjay..


02:30 pm January 24, 2020

Does this mean that the architecture/design issues like DB model is done piecemeal during the sprints. i.e if we have user login in the sprint backlog, then the db model should be created for the user login functionality only, next sprint if we have purchase order module, then the DB model should updated for PO module  and so on? 

What about other design issues like whether to use hadoop or RDBMS databases for the project? When should these decisions/ work be done? During the first sprint? If we decide on RDBMS, based on the work selected for the first sprint and then in subsequent sprints, we think that Hadoop is better suited for the product, what happens?

 


07:07 pm January 24, 2020

Does this mean that the architecture/design issues like DB model is done piecemeal during the sprints. 

Simple answer is Yes. Build what you need as you need it. Don't build something that might cover every possible eventuality in case you do need it. 

...what happens?

Change happens.  This what agile is all about.  Do the work that is needed now, then inspect and adapt based on what you learn. What happens if you pick Hadoop in the beginning because you feel like it might be important later only to find that it never is important?  You have added some complexity to the application that wasn't really necessary.


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.