Skip to main content

Creating a Sprint Backlog

Last post 06:36 pm May 24, 2017 by Timothy Baffa
3 replies
11:45 pm May 23, 2017

Hope someone can help me on this? 

I'm a Scrum Master involved in a large project that has several 'areas'. For example, there are user stories for the following requirements; enter user details; check user details; create tasks for internal users, create relevant documentation, email users, etc.....

The Development team want to tackle the user stories in a way that I'm not sure will work. For example, take the 'enter user details' story. This could be broken down in to smaller stories such as 'enter user first name' , 'enter user last name' , 'enter user address'. Obviously this isn't the format that they are actually in, just giving a rough example. Now imagine that is repeated for the other user stories, the 'check user details', etc... The Dev team want to take a few stories from each segment and effectively build a 'skeleton' application in the first sprint or first couple of sprints, and then add to this 'skeleton' during each successive sprint, so effectively 'layering' functionality. The Development environment is work flow based, rather than raw code. I know it's not my problem per se, but I'm not convinced this method will work, so I'm interested to hear what others think? 

 

 


02:41 pm May 24, 2017

Well, the review/retrospective should indicate whether or not this approach works. The product owner determins the priority and value of the items in sprint. The sprint goal should be met. The developers should determin how they get there.

But I'm also puzzled by it. What's the reason of the team to do it like that? 


04:09 pm May 24, 2017

Do each of these stories meet the INVEST criteria?

For example, is each one independent? Is it possible for "enter user last name" to be completed and to potentially enter production without the story "enter user first name"?

It seems to me that the team are not thinking about their work in terms of release quality each Sprint, and are instead trying to build up a batch of unreleased work.


06:36 pm May 24, 2017

Alan, to a certain extent, there is value in allowing the development of a thin layer of functionality (skeleton) across all areas, as a way to establish an overall architectural approach (POC).

 

As a Scrum Master, I would focus on ensuring that the team and the PO are refining stories that meet INVEST, and do not span multiple sprints.  

 

Keep in mind, it is always better to allow the team to find their way, and guide their discussions when things don't go according to plan, as opposed to prescribing a solution to the team.

 

Good luck.


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.