How to split User stories?

We have a 2 week sprint (10 business working days). The developers have been given the first 7 days to complete their coding and last 3 days are meant for pure testing. Any thoughts on this approach?

Who is giving them this time? There are two weeks. Isn't it up to the Development Team to decide how to best to use that time so the agreed Sprint Goal can be met, and a Done increment delivered?

Both the devs and tester said that even if they would have released the story for testing as n when one field is being created and placed on the form, the tester would still have to test everything, every time and that would have been time-consuming

What errors may be caught by doing that testing, and what assumptions might be challenged? How might the process be automated? Might there be an advantage in designing an automated test first, before developers even attempt to satisfy that requirement?

Doing all the dev first and then doing the testing last feels very mini-waterfall and will hurt you sooner or later..  

What happens if you don't complete the testing in time?  You have nothing 'done'.  It's far better to have 5 things done and releasable than 10 things 'nearly done'.

Think about limiting your work in progress and focus on getting dev AND test completed one story (or as few as practical) at a time.  Remember the 'I' in INVEST.  If the story is independent, it will stand up up under it's own weight and is something useful that could be released on its own.

Both the devs and tester said that even if they would have released the story for testing as n when one field is being created and placed on the form, the tester would still have to test everything, every time and that would have been time-consuming

And that's where you introduce testing automation. Yep, gotta be thoroughly tested, no argument there, however if you are continuously integrating AND your testers are working in parallel with developers on automating their routine tests, that's what makes it tick, that's what makes value flowing from the Dev Ready to the Done column.

Depending on what each field did, the tester could have easily tested the specific field and then run integrated testing when the entire form was completed. For example, fields require very specific text to be allowed, the tester can easily test that functionality on the specific field without having the entire form completed. If there is a special character, for instance, that was allowed to be entered but should have been blocked; the tester would have found that early and the dev team could have fixed this bug prior to full testing of the entire form. 

Automated testing is definitely the way to go for this but until then, if it is at all possible to test pieces of a whole; it is beneficial. Otherwise, your tester is providing no value to the team until the last few days of the sprint. 

Your question regarding should this have been a single user story with 9 tasks, versus a single user story really depends on what the form is and what the fields do. If you're creating a customer entry form when the 9 fields are basic data input; I would place this as a single user story. If you're creating a form that contains 9 separate fields that each perform a specific action, I would be more inclined to create a user story for each. Others may have a different idea on this though.

Hello Aarti,

I would like to propose an exercise to you (+ your PO and best case the whole team) about splitting User Stories -->  

it is called "Elephant Carpaccio" http://alistair.cockburn.us/Elephant+Carpaccio+Exercise.

I learned a lot when I did it myself and I conducted it several times with differen teams. 

Cheers

Joerg

Hi Aarti,

What's the reason of creating one story per field? It's very important to cut waste. Story should be based on an INVEST principle. One field and it's validation per story does not seem smart use of INVEST principle. I will advice to go through Joerg Karlinger approach and see how it helps you. Thanks.