Can we discuss user stories?
Hi,
I am a product owner for a defense contractor. We are non-profit and our budget is set by fiscal year. All of the in-house software (web app) development we do is for projects that have been approved through governance (new) or upgrades to apps we've built over time. When a new, large project comes along, say to replace a legacy system on a platform that will be retired, these projects are often pretty much fully defined as regards the functionality they must provide before they can go live (the MVP), which is very often a few to several months of work.
We follow Scrum, but my backlog (which incorporates all the projects my team supports) is quite long. I've successfully used it to gauge how much work we will get done in about how much time, which is required for resource management.
I start with epics for basic functionality (e.g., Request Funding for X-type Work). I add acceptance criteria that is high level: 1) create the request form, 2) automate the workflow, 3) provide request tracking ... which may include some criteria to determine scope (includes integration or not...). Then it gets broken into stories.
My typical approach, which has worked so far (for ~5 years now) is to break these large forms (think government forms) into sections and have a story per section. My team has always insisted that the tickets include as much detail about what is needed as possible before they'll score the the tickets. The trouble with this is that I then end up 'solutioning' too much. I find that if I do not include this, then our backlog refinement sessions become hours long debates and we get through very few of the tickets at a time, when I need to provide project timelines (even as WAGs) earlier.
If you're writing up a user story JIRA ticket that will have the team build a portion of the form and need to specify what inputs must appear on the form, the boundaries for those inputs, validations, etc. how do you do it without solutioning? Is there another approach I can try to make this more efficient and effective? I'd love to hear different ideas on this topic. Articles exist that cover a vast array of approaches, but what have you used in practice that has worked well?
Thanks.
Ginni
these projects are often pretty much fully defined as regards the functionality they must provide before they can go live (the MVP), which is very often a few to several months of work.
We follow Scrum
Why? What do you hope to achieve by doing so?
Scrum is about learning to build the right thing at the right time, under conditions of high uncertainty. Each Sprint is a learning experiment and an opportunity to maximize emergent value.
Agreed, and we do make many, many improvements over the legacy systems. Scrum works well for us for that, and we get the iterative, quick feedback from the end users. This team supports many such projects, but also projects for new apps as well. Often in a sprint we will work on more than one app at a time... we have to do maintenance releases (bug fixes and the like) as well as new development.
Scrum is about learning to build the right thing at the right time, under conditions of high uncertainty. Each Sprint is a learning experiment and an opportunity to maximize emergent value.
We are following a product roadmap, in which feature releases are of course shared with the stakeholders, with the respective dates and timelines being very important to them.
If there is the condition of high uncertainty with Scrum, and each sprints are learning experiments, it may lead into not achieving the target release dates.
Am I missing something? Or should release dates and timelines not be a part of a Scrum product roadmap?
Scrum is about learning to build the right thing at the right time. Where there is a hard date to be met, Scrum presents a team with multiple opportunities (Sprints) to learn about the best thing to build by that date.
If there is an assumed certainty about what to build by when, Scrum might not be of much help.
Thanks Ian Mitchell for your time, much more clearer now :)
To the original poster @Ginni Machamer
We follow Scrum
Do you really follow the Scrum framework or do you just use some of the terms and practices?
According to the Scrum Guide:
The Product Backlog is an emergent, ordered list of what is needed to improve the product.
Notice that it says "the product" indicating that a Product Backlog is only for 1 product. Your description sounds like your backlog contains work for many products and that you might work on multiple products in a single Sprint. How do you craft your Sprint Goals to help the team focus if they are working on multiple products? NOTE: I am saying product not project.
My team has always insisted that the tickets include as much detail about what is needed as possible before they'll score the the tickets. The trouble with this is that I then end up 'solutioning' too much.
This doesn't leave the developers much room for discovery or ingenuity. If the team wants this level of documentation it sounds like they would be more happy with waterfall where large requirements documents are provided. This would also allow you to plan multiple projects as you state that you work on.
As @Ian Mitchell has stated Scrum works best when the work that needs to be done is emergent. Your work does not seem to be very emergent so you might question whether Scrum is the right framework for you to be using.
I find that if I do not include this, then our backlog refinement sessions become hours long debates and we get through very few of the tickets at a time,
Hours long debates for refinement is not uncommon in my experience. It shows that the Developers do not fully understand the problem that is being presented. The debate to refine the problems and reach better understanding is exactly what Scrum is about. From the Scrum Guide
Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a description, order, and size. Attributes often vary with the domain of work.
No where in the Scrum Guide does it say that refinement is a meeting or event. It is not timeboxed in the current revision of the Scrum Guide. Previous 2017 version stated
The Scrum Team decides how and when refinement is done. Refinement usually consumes no more than 10% of the capacity of the Development Team. However, Product Backlog items can be updated at any time by the Product Owner or at the Product Owner’s discretion.
For a 2 week sprint, that would be 8 hours for every Developer in the Scrum Team. That is not a small amount of time. It also doesn't state that it is 10% of the capacity of the Development team spent in meetings. Refinement can happen in many ways other than meetings. Having an asynchronous conversation via comments in a Jira ticket can be quite effective for refining some items.
You never really state the problem that you are trying to solve and whether anyone else on the team feels it is a problem. This honestly sounds like a Retrospective item that you should bring to the Scrum Team. Have them help find the solution that works for the entire team. You are part of that team so you should be bringing this up with them if you feel is an issue. And since you say that you "follow Scrum" the Scrum Master can help facilitate the discussion during the Retrospective.