Creating a Sprint Backlog
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?
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?
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.
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.