Bad quality User Stories written for a technical platform migration agile project
Hello everyone,
I'm the Scrum Master of an agile project based on Scrum which deals with 'hosting platform migration' for an existing application. The nature of this project is completely technical with no conceivable change on the functionality or the user interface side for the end-users. The problem we have is regarding the quality of the User Stories created for each of the 2-weeks Sprints. Although the Stories are jointly created by the team members, they often lack a clear-cut scope for the work to be done as part of the Story or its acceptance criteria. Quite often, they change the scope or the acceptance criteria of the Stories in the middle of the Sprint itself, saying they haven't thought of that point during Sprint Planning.
Owing to the completely technical nature of these Stories, I as a Scrum Master or my fellow Product Owner is not able to help the team much on that regard and we're dependent upon what team comes up with as Stories. The result is that the quality of the Stories are very bad and they often end up getting carried over to the next Sprint as they often miss out on certain things to consider as there are a lot of uncertainties with these kinds of migration projects and the work gradually becomes clear once team starts to work on them. Is there anything I as a Scrum Master or the Product Owner can do to bring about clarity of scope and acceptance criteria to the Stories so that they can be finished well within the limit of the Sprint and can then be reviewed?
Thanks in advance for your responses!
I'm the Scrum Master of an agile project based on Scrum which deals with 'hosting platform migration' for an existing application. The nature of this project is completely technical with no conceivable change on the functionality or the user interface side for the end-users.
In your view, what makes this project a good candidate for agile practices based on Scrum? How would value be maximized through empirical process control?
Thanks for your response Ian!
Your question is quite fair to be honest. To answer what value would we want to maximize, that could be quantified in terms of millions of dollars saved by moving from an on-premise legacy platform which are expensive to maintain to a modern cloud-based platform as well as from the point of view of getting quality developers to enhance the functional capabilities of the application with time once moved on the modern tech-stack. I know these won't add any value to the end-users but the huge amount saved on moving to a cloud based solution is no less than 'money earned'.
Coming to the point of maximizing the value through 'empirical process control', that's a hard nut to crack. Although all the Scrum ceremonies aid in having the empirical process control in place, the Scrum Master (me) & the Product Owner are not able to empower the team in maximizing the value gained through Sprint Planning as we're not able to ascertain what would constitute the 'just enough' knowledge about the Stories to be worked on, considering their completely technical nature. We're just able to help team with the 'format' of the Stories but not the content. Same goes with the Retrospectives, team is not able to figure out the best way to learn from their past mistakes as there are so many different legacy technologies at play and so little of a learning curve to offer given the quick turnaround time client is expecting.
We're really struggling to empower the team to get the maximum value delivered using the process controls in place and we seem to be running out of ideas. Any help will be tremendously appreciated!
My advice would be to consider dispensing with user stories altogether, and frame Product Backlog items in terms of risk mitigation. There's nothing to stop a Product Owner from ordering a backlog by risk.
You say there are lots of unknowns in this migration project. Anything which helps the team to agree and meet Sprint Goals which brings this complexity under control, and mitigates risk, would therefore appear sensible.
A risk burn-up may help:
https://sites.google.com/site/wicmitchell/home/risk-burn-up-daring-deeds-in-devops
I'm with @Ian Mitchell on abandoning User Stories. User Stories are not part of Scrum, they are a convention that a lot of people have adopted. The Scrum Guide states:
Product Backlog items have the attributes of a description, order, estimate, and value. Product Backlog items often include test descriptions that will prove its completeness when "Done".
Notice that nothing is said about the format. Have the Development Team provide all of the attributes listed, then the Product Owner can order the backlog appropriately. Again, ordering of the Product Backlog can be done in any way that makes sense for the Product and the work.
As Scrum Master, you should focus on helping the Development Team understand and refine their methods of capturing the work and forget all about "standards". It may be better for them to write small technical requirements documents instead of User Stories.
You should help the Development Team in ways to effectively communicate the needs and value of each body of work to the Product Owner so that they backlog can be ordered. Another quote from the Scrum Guide. This if from the section that describes the Product Owner role and immediately follows the list where it states the Product Owner is responsible for ordering the Product Backlog.
The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable.
You should help the Product Owner understand how to order the backlog in a manner that is most appropriate. This is your duty to the Product Owner of "Finding techniques for effective Product Backlog management;". (Quote taken from the Scrum Guide). This might be a case where the Product Owner has the Development Team do the work.
You state that the work has no direct benefit to the user. I argue that is untrue. The "user" does not have to be an end user of the application. It can be any user. In the case of your situation, the users are the development staff that has to maintain the application code, the operations personnel that maintain the systems on which the application run, the Product Owners that discover opportunities for product enhancements. There is significant user benefit to the work that you are doing. If that helps the Scrum Team to better understand the work, then frame your Product Backlog Item statements in a way that shows the benefit to those users.
Stop thinking about this as a process. Think of it as a body of work that needs to be accomplished for a specific purpose. Use empiricism to guide the way to delivery but don't make it a rigid process that must be followed. Throw away all of the previous process and development a new way of handling this work. Inspect, adapt, repeat.