Can we split a large user story as analyse and develop?

Just to get it out of the way: Scrum does not require the use of User Stories. User Stories originate with Extreme Programming and many Scrum Teams do find them useful as one way to express a Product Backlog Item, however, they are not the only way and, even if they are used, not all Product Backlog Items need to be expressed as a User Story.

With that out of the way, let me give the rest of the answer.

What you describe as "development analysis" is very much aligned with what Scrum refers to as "Product Backlog refinement". Refinement is an ongoing activity, performed by the Developers in coordination with the Product Owner, to decompose Product Backlog Items into smaller and more precise elements. Previous iterations of the Scrum Guide have recommended that about 10% of the capacity of the Developers is allocated to refinement activity, but this recommendation was removed in the 2020 revision.

Another useful concept is that of Spikes. Spikes also originate from the Extreme Programming community. The purpose of a Spike is to figure out how the team can approach a problem and get to a deliverable solution. There's no widely accepted format for how to specify a Spike like there are recommended formats for expressing User Stories.

Personally, I find Spikes to be an extension of refinement. Sometimes, refinement is straightforward. Other times, there are specific questions that need to be addressed, often through research or experimentation. Depending on how you manage your Product Backlog, I've found that placing the Spike into the Product Backlog and making it clear that it is blocking the refinement of Product Backlog Items can help the team focus their refinement activities. It also has the added benefit of making the team aware that they have something that may require a focused effort during a Sprint, increasing transparency about what the team is doing to all stakeholders.

The only recommendations that I'd have are that you don't need to express your Spikes in the User Story format and you can also consider timeboxing them instead of sizing them in Story Points. They are, after all, a different type of work and I'm not sure that it makes sense to treat them in the same way as a deliverable change to the product.

Is it ok to split a user story into "development analysis" and "development"? 

If you did that, would you get empirical feedback from releasable work every Sprint?

if you did that, would you get empirical feedback from releasable work every Sprint?

Maybe, why?

Thomas, I think that the user story we split is not an example of a "product backlog refinement" activity. It is the result of refinement. The question is, is it ok to split like this. The product team already write analysis document, use case diagrams, screen designs and so on but there are things to be done right before starting development and this is an effort and part of the development process. 

This is our purpose why we do it like that: if somehow we can't finish all of the user stories, we can move the part we didn't make to the next sprint. I mean :

• As a user, I want to save my Personal Information so I can use this info for my driver license application (35 SP) DONE
• As a user, I want to send my Personal Information to the government via the internet so I can apply for a driver's license. (35 SP) DONE
• As a developer, I want to analyze/learn how to use the government official API's so I can start to develop related API (30 SP) NOT DONE, MOVE TO NEXT SPRINT

30SP failed instead of 100SP. This gives us a more precise burndown chart. What do you say?

> if you did that, would you get empirical feedback from releasable work every Sprint?

Maybe, why?

The Scrum Guide says: "Scrum is founded on empiricism and lean thinking. Empiricism asserts that knowledge comes from experience and making decisions based on what is observed."

Thomas, I think that the user story we split is not an example of a "product backlog refinement" activity. It is the result of refinement.

Splitting a User Story is the result of refinement. However, the third "User Story" that was created represents additional refinement. The Scrum Guide says that refinement is "the act of breaking down and further defining Product Backlog items into smaller more precise items". By analyzing and learning how to use the official API, the Developers will be able to create or decompose additional Product Backlog Items into User Stories or whatever other format is suitable to capture valuable changes to the product.

The question is, is it ok to split like this.

I believe that it is OK. The third "User Story" that you have is what I would consider a Spike. By completing that Spike, the team will now have enough information to identify what User Stories can be done in upcoming Sprints and making sure that all of the other Product Backlog Items (or User Stories, if that's how they are written) are well written and sized according to the team's practices.

Once again, I'd make two suggestions:

First, I prefer to timebox Spikes rather than size them in the same way as User Stories. The timebox could be something that is specific, at some level of granularity, like a maximum number of hours or days. The timebox could also be a deadline, such as an upcoming refinement session or the end of the Sprint. When teams use Story Points and Velocity, I don't believe that a Spike should count toward that Velocity.

Second, I'd consider using a format other than the User Story format. The developer is not someone who uses the system. User stories should focus on the people who interact with the system as it is being used - people who provide data or consume data. The developing organization shouldn't be represented. You don't need to use the User Story format for all Product Backlog Items - I find it overly constraining to have to think about everything in those terms.

30SP failed instead of 100SP. This gives us a more precise burndown chart. What do you say?

I don't recommend thinking about it as "failed". You do not "fail" Story Points. If you want to use "failed" in the context of a Sprint, I would recommend thinking about it in terms of the Sprint Goal rather than outputs. This can help the team and the broader organization start to think about outcomes and objectives over output. Even then, I prefer to talk about meeting or not meeting the goal, and not failing the goal.

I would also not do things just to get a more precise burndown chart. You're already doing work that isn't on a burndown chart anyway. You probably don't estimate and burn down refinement, process improvements, and non-product work. Since a Spike is just an extension of refinement, it doesn't need to be estimated and burned down in the same way.

Is it ok to split a user story into "development analysis" and "development"?

@Murat Gür, To simplify the answer to your question If your Developers cannot take that user story and start development and testing in the upcoming Sprint, then all the work that you need to do in order to get it to that state of readiness can be considered as Product Backlog refinement.

What would you accomplish by splitting a user story for analysis?

As a developer, I want to analyze/learn how to use the government official API's so I can start to develop related API (30 SP)

Just to extend what others wrote - What's the outcome for this user story ? Isn't analysis anyway a prerequisite for any new work taken (or work with no prior experience)  ? Do you think this learning might still continue even when development is initiated ? 

I agree with @Thomas Owens' Spike statements.  I have used Spikes with many teams in the past with success.  However, your statement is too broad for a Spike. It is just saying "we need to learn everything in order to do something".  That is analysis and doing due diligence before creating a new functionality.   A Spike would be written to learn about something very specific.  I'd suggest something like 

As a developer, I want to analyze/learn valid input to the government API so that I can determine if we have the necessary information to build a related API. 

That is very specific and can be measured.  In fact, you could do multiple Spikes of that manner and be able to validate your progress.  The way you have phrased it could never be accomplished because I'm sure the government is maintaining their API which could lead to changes in the way you will need to interact.  It could also solve your problem of something not being completed in your Sprint. 

Having given that example, I coach that Spikes be used sparingly.  They should only be used for extremely important and specific use cases. They frequently involve crafting some kind of throw away work that is used to validate your assessment.  This kind of analysis is just part of your job as a developer.  You should always analyse things so that you can understand how to improve them.  The same could be said for every time a new version of software roles out. For example, if you use Java do you create stories to investigate updates to the SDK? I would bet not and it is assumed that developers due diligence will cover that. 

I am going to go even further and say that the story you wrote is actually work to assess a new product/feature opportunity.  It is opportunity assessment which comes even before Product Backlog refinement. The Scrum Guide explains the Product Backlog with these statements:

The Product Backlog is an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team.

Your story does not describe something that is "needed to improve the product". It describes an attempt to discover if there is something you can do.  If you already have an improvement idea related to the use of the government API, then that story could be rewritten to support that idea and become a more focused Spike. But the way you have phrased it does not indicate that is the case. 

Keep your Product Backlog focused on items that are related to "what is needed to improve the product" in order to keep the Scrum Team focused on their work.

Wow, really good answers.

 As far as I understand, looks like the 3rd user story can be considered as a spike and spikes should be time-boxed and it is part of the job. So I'm thinking about why we wanted to give an estimation of it. The answer is team capacity concerns. Here is the math:

• "Developer 1" takes 100 story points on average. If we write 1 or 2 user stories just for the measurable part of the work and write 1 spike, it will be 60 SP and 2 day work and this will look like he/she (team) is doing less work. Because we use burndown charts to measure what we do.  Maybe we should change how we think about SP's.

Does this lead us to another question? Isn't this effects our velocity? This question discussed under this topic: https://www.scrum.org/forum/scrum-forum/30937/how-estimate-spike-stories

I think we will do as I said before. We will split the User Stories and we will continue to measure the spikes with Story Point. This will keep our velocity in a healthy situation but I need to measure the value we delivered every sprint. 100 SP done but 60 SP value delivered. 

Thanks for your answers guys, really appreciate it. 

• "Developer 1" takes 100 story points on average.

Are these 100 points just for the development or for the story from start till its closed/done? How does your team collaborate in making any task as done?

If we write 1 or 2 user stories just for the measurable part of the work and write 1 spike, it will be 60 SP and 2 day work and this will look like he/she (team) is doing less work. Because we use burndown charts to measure what we do.  Maybe we should change how we think about SP's.

I would like to ask what do you think is more valuable here - to achieve the Goal which contains your split stories irrespective of their points ? or to make sure to management that team velocity is undisturbed ? 

If an average velocity which is used for forcasting sprints is used as performance indicator then how easy you think is to manipulate it ? In your example team can estimate the first 2 stories as 50 each and deliver them. There is no impact with velocity although i see value delivered is not what you expected. Also, what meaning these story points have when you deliver an increment to the customer ?