Jira Agile Scrum Plan Mode Estimates for Story Points

[David Wilson]

We use the Scrum board Plan mode for planning, and we create Future Sprints to pre-plan our sprints. In order to properly pre-plan, my team needs to go estimate their workload.

Now, I understand that Subtasks are meant for the technical breakdown of a functional story. This makes sense to me. However, give that the TECHNICAL requirements of a story vary based on the type of team completing the individual subtask (e.g. a Story to implement a report has both a database component and an a Web UI component), the estimates need to be made at the subtask level.

Great. I can do this with the "sum story points on subtasks" setting. So far so good. [EDIT: scratch that... this is only a setting on the classic board, not the new JIRA Agile scrum board. SO, this is also a problem for me]

Back to the pre-lanning scenario. As PM, I assign all the tasks to the proper team members who will perform the subtasks. I then say, "Hey, go to the Plan mode of the board, and estimate any issues assigned to you in the future sprints". No subtasks get estimated.

Why? because the "Only My Issues" filter does not show stories that have subtasks assigned to me! So how do I modify that filter (or create another) that shows STORIES that contain subtasks assigned to me? How are my team members supposed to know what they need to estimate, if they can't see what is assigned to them in the PLAN board (the name of the board says it all... it's about PLANNING).

As an aside, the followup issue to the PLAN board is that I can't see the total story points assigned by user. On future sprints. It makes it hard to properly "plan" a future sprint if I can't see the effort required of each individual team member. So what if my team can collectively accomplish 200 story points in a sprint... if 195 are all assigned to the same person, we're going to miss our mark.

If it was a scenario where we just let each member pull from a list to fill their workload, we'd use a Kanban board, not Scrum.

So, my question (s):

A) is there a good JQL query to create an "Only My Issues Plus Issues with My Subtasks" filter?

B) is there a good way of summing story points by User, shy of creating a filter for each member (which still would have the same problem as issue A above, unless I can solve issue A) ? Note: I'd be willing to even have a standard JIRA report on this where I filter by Future Sprint name, and see the breakdown from there... though a method within the Plan Board would be better.

If there's no good solution to A, or B above... I have a suggestion for the JIRA Agile Devs to facilitate the planning deficiencies (as a dev myself, I understand this is just a suggestion... but it's how I would implement it).

Create a 4th Mode on Scrum called "Estimates". It should look exactly like the Plan mode except:

* it should only show Future Sprints and Backlog.
* subtasks should be shown nested below their Parent issues.
* Drag and Drop should be disabled
* There should be a breakdown of points assigned to each user within each sprint (this should also be implemented within the PLAN mode... maybe a tooltip on-hover over the estimates total at the bottom?)
* There should be a breakdown of issues (and subtasks) by user of how many issues assigned vs. how many still need estimates.
* "Only My Issues" filter would then naturally work with the subtasks because they are visible (just like it does in the Work mode, once a sprint is started)
* Assignee should appear on the issue bar itself (just like version and epics do)

Can I get around this today? Sure... but it sucks. It requires that each user be notified that they have subtasks waiting on estimation results. It also makes preplanning a sprint super difficult because I have to keep track of subtasks assigned to each member MANUALLY to properly vet that they don't have too large of a workload.

I like the Agile tool. It jsut needs some extra love.

[Deleted user]

Not possible in regular JQL, but the j-tricks plugin (http://www.j-tricks.com/plugins.html) will do this with

issue in subtask("assignee = currentUser")

See here for more... http://www.j-tricks.com/jqlt-subtask-functions.html

[Keith Thomas]

To get the full benefit of the Scrum Agile framework for our project we should try to follow the recommendations as close to 100%, as possible. I have heard from several groups who have attempted to go Agile Scrum expressing difficulty in following the recommended procedures. "It doesn't work for our business model.", they say. "However, Scrum-but works fine". That may be well and good, but bear in mind that the ROI for following the framework recommendations is much higher in the long run than not doing so. It is a matter of business choice.

I also believe much challenge will remain if we hold on to the traditional waterfall mindset, while trying to adopt Agile Scrum. This is a totally revolutionary process requiring a changed mindset.

My two cents.

[David Wilson]

Again, while I appreciate the input about "Why you should Scrum the way Scrum was meant to be", it's not a helpful answer for my OP. Let's put the nomenclature aside and just call it "David Wilson's Business Process Framework", or DWBPW for short, OK, and not pretend I'm trying to scrum? I'm not looking for training on how to Scrum-with-the-best-of-them. What I'm looking for is how to get the TOOL to do what I need it to do.

We can argue the merits of Scrum in its pure form until we're blue in the face, but this isn't a topic on why I should switch to Scrum. This is a topic on how to interface with the JIRA Agile platform to support one's own business processes.

I think Atlassian may have done a disservice to their platform by rebranding it JIRA Agile, because now every topic on the program devolves into "Well that's not how Agile is meant to be". I acknowledge they had the Agile process framework in mind for the problems Jira Agile was meant to solve, and as a developer I understand that solving the RIGHT questions is often better that trying to solve EVERY question with a program.

That said, I believe JIRA was always meant to facilitate anyone's process, and JIRA Agile can still mean that end without taking away from it's original and primary mission of supporting the Agile process.

So with that in mind, I appreciate your two cents, but it's wasted as it doesn't answer my OP.

[John Price]

Hi David -

Lots going on in your question. For finding "issues that have subtasks assigned to me" (but where the parent isn't) I don't know of a built-in way, but I found this question that suggests the CraftForge JQL plugin.

If I may, I think the bigger issue is with the way your sprint estimation and planning is happening. If I put my CSM (Certified ScrumMaster) hat on I see a couple of red flags:

1) "As PM, I assign all the tasks to the proper team members who will perform the subtasks." Generally a PM/Product Owner does not create or assign subtasks (or even stories). The PO's job is to bring a prioritized backlog of stories to the team. Tasks are claimed by the team members during sprint planning.

2) "Hey, go to the Plan mode of the board, and estimate any issues assigned to you in the future sprints." Story estimation should be happening in a group estimation session that includes several team members or the whole team. We make time for these during a midpoint of each sprint so they don't interfere with the current sprint too much. Sub-tasks should be created by the team as a group during sprint planning (just before each sprint). Stories that are two or more sprints out probably wouldn't have sub-tasks yet, unless someone just adds one they don't want to forget later.

There's lots of variation in exactly how teams accomplish these things, but the above two items are pretty important to follow. In general teams that have people assigning stuff *to* them are less invested in the work than teams that figure out what the tasks are and self-commit to them. Some teams don't even assign all the stories and tasks during sprint planning but just assign the first few and then wait to see who needs more work a couple of days in. Of course you need to get the total capacity about right, and if you have wildly different skillsets (UI vs. db, etc.) that factors in.

If you haven't, you might check out a planning-related book like Mike Cohn's Agile Estimating And Planning or something similar.

Hope this helps!

[David Wilson]

#2c Additionally, we need to ESTIMATE (which means pre-development), and that will drive backlog decisions. We don't look too far into the future, but we DO look at least 3 sprints out. This gives us time to change sprint plans with a pretty decent idea of what's up and coming. This helps the Product Team/Executive team drive items that are slotted, and helps make decisions on the backlog. Why? because I may decide that Item A is more important than Item B... UNLESS Item A is going to take XXX amount of time, in which case Item B actually takes precedence. Item B may have a more restrictive timetable than Item A, but Item A may be better to the bottom-line. So the decision of priority is largely based on the Estimates. Thus I need to be able to pseudo roadmap the "near" future, and in order to do that I need to Estimate ahead of time. So again, looking into the future is a necessity.

The point? While I appreciate your "here's how AGILE should work" input, it doesn't fully work for my team. What we do currently works very well (in terms of the process, establishes personal ownership over workloads, and manages expectations across many departments in an effective manner. BUT... the tool still has some deficiencies. I still need to efficiently manage estimations among my team.

You could argue that JIRA AGILE is mean for a fundamental Agile team, and therefore not meant for a team of my nature. I could possibly agree with that. However, it's also the closest tool to what I want. It works so well for just about everything else I need. And I imagine that my request for better management of estimates doesn't fly that much in the face of Agile that it would change the nature of the tool into something unusable by fundamental Agile teams.

[David Wilson]

Hi John. I appreciate the input. However, the philosophy on "True & Blue AGILE" is not particularly helpful considering we aren't a fundamental AGILE shop. The JIRA AGILE tool is extremely helpful, even without being an AGILE fundamentalist group.

So, for #1, we DO assign tasks based on a number of factors: the skills required; the desired milestone date; the learning opportunity for different developers to get exposure to different code; etc.

#2a This may work for you, but frankly, the idea of everyone sitting in a meeting discussing how long something will take is a HUGE time suck. We follow a "happy medium"... eveyone estimates their assigned tasks. We then meet as part of a "retrospective/future planning meeting", and everyone then presents their estimates as we go through the issues. This is generally very quick, unless there are standouts, in which case there's a group discussion. This saves tons of time.

#2b We still need to FUTURE ESTIMATE these items, and subtasks are definitely a requirement. Most of our items have multiple components of work performed by multiple people.
EX: Want a new report? That's a DB team subtask, a web team subtask, and a subtask for Wiki documentation (likely by a different team).
The story is the report and the purpose it serves. It may/may not be in a Large EPIC. The Subtasks are the pieces that make up the whole. Each piece is estimates by their team (and more specifically, the individual to whom the subtask was assigned). Estimating subtasks is a must.