Data Base Design / Model

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?

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 ?

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.

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

Thank you Alan

Thank you Sanjay..

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?

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.