How would you do this?
I've been tasked with coming up with a report that generates the following:
What a team is working on from a medium high level, meaning not the individual stories, but not the epic either.
Of that work, what was committed to in this current sprint.
When the sprint is over did they deliver the work they committed, and if not, why?
How are they tracking towards their delivery date?
So, in our org our cost and time are pretty fixed, it's the scope we're allowed to play with. The issue I'm facing is that the teams over the last year have been absolutely HORRIFIC about updating JIRA. They will add stories late, not point them, create and close them within minutes, it's almost impossible to actually track velocity because the teams are just lazy as hell when it comes to clerical work. I am SO pro no metrics at this point, but my VP is a metric guy and so we are a slave to providing metrics, that no one wants to actually provide.
The best I've been able to come up with so far is creating a New Feature item in between the Epic's and Stories that defines better than an Epic but is more high level than a story, and create an excel sheet from JIRA after the team has committed to their features for the next 2 week sprint.
At the end of the sprint, they must show their progress / completion on an updated form of that spreadsheet with a column for impediments if they had any, but is required for any feature committed to that is not delivered.
Then simply wrap that into a % based on number of features closed, obviously for less well defined projects this becomes a guessing game as new requirements are being identified along the way, but consistent progress is expected.
Would you do this differently?
I've been tasked with coming up with a report...
How is the Product Owner currently accounting for value to stakeholders? Why is this report thought to be necessary?
It sounds as though the team struggle to maintain transparency over the work they are doing even among themselves. Perhaps this is the immediate issue which ought to be exposed and addressed.
Would you do this differently?
In a heartbeat!
----------------------------------------------
Ok, joke aside, some serious questions/concerns about your situation:
- It is critical that all parties involved understand that the Development Team is making a forecast of what they believe they can complete by the end of the sprint. It is not a commitment
- What is your role in the Scrum Team Jon? If you are a Product Owner, some of these measurements may already be available to you. If you are a Scrum Master, work with the PO to identify ways to provide management with the data/metrics they are seeking.
You definitely do not want to accept responsibility for reporting status to management, as this can easily undermine your relationship with the rest of the Scrum Team.
- I would openly question why your management (specifically your VP) is interested in activity and output-based metrics. Such measurements may provide insight from time to time around team issues, impediments, and efficiencies, but they provide none of the critical measurements around value delivery and customer happiness.
You need to coach your VP on why his proposed team and project-based metrics are so minor in comparison to what he really should be measuring
- Unsure why your Development Team is so sloppy around Jira maintenance. Has this been discussed with them? Are they aware of the need and benefit of being fully transparent and accurate regarding the status of their forecast work?
It is critical that all parties involved understand that the Development Team is making a forecast of what they believe they can complete by the end of the sprint. It is not a commitment
Exactly. Small post on this on my LinkedIn: https://www.linkedin.com/feed/update/urn:li:activity:6536230081310834688
Ever tried to put the team and the VP in a room together and have them understand the need of transparency and how to facilitate this? Maybe it's metrics, maybe it's working on JIRA, maybe it's a proper Kanban. Facilitate the discussion and see what you can come up with.
How is the Product Owner currently accounting for value to stakeholders? Why is this report thought to be necessary?
We don't have any product owners and we barely have any relationship with our stakeholders / customers, it's a cluster I know, but I'm doing the best I can with what we have. We have some people who seem to just not want to work around here, so we gotta kind of keep on top of them, this report is an attempt to hold people accountable.
- Unsure why your Development Team is so sloppy around Jira maintenance. Has this been discussed with them? Are they aware of the need and benefit of being fully transparent and accurate regarding the status of their forecast work?
Yes, at length, they all think scrum is a joke and that documentation and updates etc are just getting in their way, when in reality, we're asking for 5 mins of their time every day, it's not a big ask, they're just lazy and don't want to do it.
It is critical that all parties involved understand that the Development Team is making a forecast of what they believe they can complete by the end of the sprint. It is not a commitment
That's not what I was taught at my scrum class, I was told that it's a commitment, and while the dev team may not meet that commitment, they're expected to get better at guestimating their work over time and in the end they'll be able to provide better commitments.
As I understand it the waterfall method was that we had fixed Time / Scope but Cost was the variable factor. Whereas with scrum, Time and Cost are fixed and Scope is the variable factor. Meaning that we're allowed to be told you must have a car built 6 months from now with 6 team members, but they're not allowed to tell us it must be a mustang, if it turns out to be a honda civic then maybe we continue after 6 months doing upgrades until it's closer to a mustang, but that's up to the customer / business to decide.
It's hard to explain the place I work at, the level of moral in the org is basically 0... We've had several people quit in the last few months because of it. I've made it abundantly clear that our BIGGEST issue as an org is our serious lack of product ownership / vision, and our seemingly completely lack of customer relationship. I'm told that a lot of that is unfixable because we can't hire, and the requests come to us from inside the company, through PM's that may or may not respond to us if we ask them to attend a meeting... On top of that, some of our projects have multiple stakeholders and getting them in the same room as the dev team has been my driving push for the last 3 months, and I have yet to be able to get management to make this happen.
I would do it myself but I literally have no clue who is the stakeholder / customers of these projects, none of the scrum teams do either, so it's not like we can self-organize, we get spoon fed everything.
That's not what I was taught at my scrum class, I was told that it's a commitment, and while the dev team may not meet that commitment, they're expected to get better at guestimating their work over time and in the end they'll be able to provide better commitments.
Who ever taught your Scrum class really needs to read the current revision of the Scrum Guide. In the 2011 revision (https://www.scrumguides.org/revisions.html) this was changed.
- Development Teams do not commit to completing the work planned during a Sprint Planning Meeting. The Development Team creates a forecast of work it believes will be done, but that forecast will change as more becomes known throughout the Sprint.
I found it very useful to read the revision history for the Guide as it gave me some insights into the evolution and helped me debunk some of the misconceptions others have. Start at the bottom and read up (i.e. chronological).
As many have said, this should fall to the Product Manager to provide the information being requested. By asking you to do it, the executives are asking you to be a Project Manager.
I remember many of your questions here and it really does sound like someone in the upper levels of your company read something on a website that said agile would solve every problem and make things go faster. Yes, that can be true but not without a whole lot of changes in the way the business operates. That is that part that is always left out of those executive targeted articles.
You sound like you believe in this and are not afraid to speak up. I admire you for that. It might be time for you to talk to your execs and ask if you could set up a half day "seminar" where you give them the real basics of agile. Forget all the stuff that execs usually get and give them Scrum Team level training. I mentioned half day because that is asking a lot of execs but you really can't do justice in any less time. If they balk at that, ask for a weekly series of 1.5 hour meetings and make it clear that they will be a "no device" sessions so that they can focus on what you presenting. If someone misses, go directly to them and ask them why. Lead by example and show the courage, trust, respect, transparency that are important. After you do this, repeat with anyone in your organization that is considered a Product Manager. Teach them what role they play. Then repeat with Developers.
At this point I'd start over and focus my efforts on getting the organization to understand the premise, concepts and benefits of agile practices and empiricism. Until they start to see the benefits of those, agile at this organization is just going to be a buzz word that means nothing.
Jon Joe, I sympathize with your situation.
I will only comment on a couple statements you made though:
We don't have any product owners and we barely have any relationship with our stakeholders / customers
I don't mean to sound harsh, but based on that statement, you are definitely not practicing Scrum where you work. It is therefore near impossible for you to receive valid advice/suggestions from a Scrum forum on your situation.
That's not what I was taught at my scrum class, I was told that it's a commitment, and while the dev team may not meet that commitment, they're expected to get better at guestimating their work over time and in the end they'll be able to provide better commitments.
Jon, I'm not familiar with your Scrum class, but if that is what you were told, it is both inaccurate and unfortunate. The idea that Development Teams commit to sprint work was removed through the 2011 revision of the Scrum Guide, in favor of forecast. There is a very distinct difference between the two, and it is important to understand.
My suggestion is to search for both words "commitment" and "forecast" in the latest Scrum Guide, and see if that helps.