Vertical Slicing of User Story for API/Web Service developmet
Hello Everyone,
I want to split the user stories in such a way that each user story can be completed in 1 or 2 days. I went through lot of blogs on this and observed that vertical slicing of user stories will be a better option. But I'm stuck on how to vertically split the user stories for RESTful APIs/Webservices.
Till now we were using API document as a basis for development of a user story. API document will have which http method to use, what would be the response in case of success/failure, field definitions, etc..
For example: Let take a user story where I want to create a user using RESTful API. For this I used to create a document with complete details like
http method:POST
payload formats: JSON/XML
authentication mechanism: oauth2
http status in case of success: 201
location header: /users/<user id>
http status in case of failure: 400
exception messages:
.....
.....
Field definitions like
FIELD_NAME DATATYPE MANDATORY
=======================================
FIRSTNAME STRING(50) Y
LASTNAME STRING(50) Y
MIDDLENAME STRING(25) N
DOB DATE N
....
....
Can someone help me in splitting this kind of user stories such that development of each user story can be completed within 1 or 2 days.
Which options does your Scrum Team suggest ?
Is your focus on completing development in 1-2 days, or meeting your team's Definition of Done in 1-2 days?
We are planning to split the user stories such a way that development can be done in 1-2 days meeting team's DOD.
Posted By Somasekhar Reddy Palle on 24 Jun 2016 03:03 PM
We are planning to split the user stories such a way that development can be done in 1-2 days meeting team's DOD.
Somasekhar,
I guess I am a little confused now. Apologies in advance if it is just me.
There are definite benefits to creating similarly-sized stories (reduced variability, improved sprint flow, possible elimination of relative estimation).
However, what is your DoD criteria that requires code complete in 1-2 days? If coding were to take 3 days, is that considered a failure? What other criteria are part of your DoD besides development/coding? What is the length f your sprints?
One splitting strategy that has worked well for me and others is to split stories based on outputs or deliverables. Split stories by platform, by screen or report content, whatever is directly facing the business that they can use and gain value from it.
Once you have that division, all work is then defined as tasks that roll up under the story.
Keep in mind that if your team builds something that the business cannot use, it is either incomplete, incorrect, or unimportant.
Timothy,
Thanks for your response.
Code complete in 1 or 2 days is not a DOD criteria. All the user stories that our team estimated till now are exceeding 40 hrs. So basically I'm looking for splitting the user stories such that each user story estimate will be in the range of 6 hrs to 12 hrs.
As we are working on development of Web services, I'm looking for help in splitting up the user story for web services like creating an entity, updating an entity, etc...
May be some example on splitting the user story for creating an entity using web service helps.
Thank You
Timothy,
Thanks for your response.
Code complete in 1 or 2 days is not DOD criteria. All the uses stories that our team estimated till now are exceeding 40 hrs and it will be very late for getting the feedback. So I'm looking to breakdown the user stories in such a way that any user story can be completed in 1 or 2 days.
I have referred the following article and trying to implement the same in our product development- http://blogs.adobe.com/agile/2013/09/27/splitting-stories-into-small-ve…
So I'm basically looking for some examples how to split the user stories for web service development.
Howdy, Somasekhar! Vertical slicing is a great technique. Sometimes those vertical slices are very "tall" because they don't require work in other layers and that is okay. While many consider it ideal for a user story to represent no more than a day or two of work, sometimes that is just not practical. The Development Team should slice them as thinly as it feels comfortable and the Product Owner can accept the risks of longer efforts.
Hi Mr. Reddy, I know, a long time since your original post, but for those net surfing who happen upon here, I have some suggestions in the link below.
http://www.scrumcrazy.com/User+Stories+to+Represent+Backend+Services%2C+Web+Services%2C+SOA%2C+etc
(having trouble getting the linking to work)
http://www.scrumcrazy.com/User+Stories+to+Represent+Backend+Services%2C+Web+Services%2C+SOA%2C+etc