Sprint Goal Advice
Hi all,
I'm looking for a bit of advice regarding a project I'm about to scrum master. The project in question occurs yearly and is heavily waterfall based. This is the first year we're going to try and run it in an agile way.
The way it currently works is that the business generate units of functionality as Enhancement Requests in a helpdesk system. Looking at the requests, they can be broken down into multiple user stories. The helpdesk system has to be used, but my idea was to store the stories in Pivotal Tracker or similar, tagging them with the incident name.
Issues arise due to the tech stack and business processes the developers have to use. To push any update to dev, takes in excess of 3+ man hours. This is something we cannot alter (for now). The devs are flagging up valid concerns that pushing individual stories to dev (for the PO to view) would waste huge amounts of time.
My idea is to use sprint goals based around the initial Enhancement Requests. So multiple stories can be pushed to dev as a goal. My concern is that one sprint might see time for multiple Enhancement Requests to be complete, but sprints only have one goal.
It would be great hear opinions on how people more proficient in scrum would approach this.
In any lean or agile system, flow should be pull-based, not push-based. Each release should result in timely empirical feedback and the opportunity to modify both product and process.
If changes still only need to be made annually, is there any demand here for enhancement requests to be individually released?
Hi Ian,
thanks for taking the time to reply. To clarify, the enhancement requests will be pushed to production as one release (this is ok.) But they need to be pushed to dev individually for the PO to review them, and check them against the acceptance criteria.
For now, we cannot circumvent the Enhancement Request (ER) system, so I need to find a way to work with it. The PO will also be checking the completed stories against the ER to check for compliance.
If we run a good project, and show the benefits of agile over their waterfall approach, we should be in a better position for moving away from their current system for future releases.
Since:
- work is being pushed through the system, rather than being pulled in response to clear demand signals
- the team are producing work which is not necessarily of release quality, and which a Product Owner considers it necessary to check
- there is only one opportunity for release, and this is apparently thought to be OK
how can the benefits of an agile way-of-working be demonstrated?
My suggestion would be to focus on transparency in the first instance. Make it clear that agile practice is not yet in effect, that there are a number of shortcomings including a deficit for release, and that the benefits of an agile-way-of-working really shouldn’t be expected at this stage.
The devs are flagging up valid concerns that pushing individual stories to dev (for the PO to view) would waste huge amounts of time.
Why does the Development Team have these concerns? Why are they considered valid? Who is the Product Owner for this Development Team, and why does it seem they are not in control of the work that the Development Team forecasts?
My concern is that one sprint might see time for multiple Enhancement Requests to be complete, but sprints only have one goal.
Yes, each sprint has only one goal, and that goal is to help provide focus and direction regarding the business objective. While it is certainly ideal for all sprint items to support the Sprint Goal, there can be other lower-priority sprint items that a team can forecast in their Sprint Backlog.