How to include and manage Project Management time in a sprint?

[IT Administrator]

Am clear about estimation and tracking in Jira for my Scrum projects for each issue - but how do I / should I track project management time within a sprint / project?

Should a sprint have a 'dummy user story / PBI' against which PM time is estimated and tracked?

Am I thinking about this wrongly?

What is your advice and guidance?

[Jack Brickey · Accepted solution]

This is really more of a discussion than a question as there isn’t a ‘right’ answer except what works best for you. With that said, IMO you don’t need to track PM time in a development sprint. While the PM is certainly part of the team I don’t see the value of blending their work directly into a scrum that is focused on development. As a PM, if I felt the need to track my work I would likely do on a separate board. With that said, if I were to track on the scrum, how I did so would depend on whether I had well defined tasks or not. If so, I would include each task and if not I would have a single task as a catch-all.

[IT Administrator]

Hi Jack, thanks for your reply.

It's probably that I'm still wrapping my head around what Agile is or is not and how to effectively use methods like SCRUM in helping achieve an Agile culture and outcomes, but my understanding is that SCRUM is not simply a development approach.

To quote Schwaber and Sutherland, they define SCRUM as 'a framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value'.

In that sense, I understand that SCRUM is not a methodology as much as an approach to complex problem solving using empiricism. But empiricism also demands measurement (not just 'story point' complexity, but also units of time) in order to understand and forecast sprint progress. The various JIRA reports provide different views on this progress through Story Point but also time-based measures.

One article I read about Agile Project Management said 'Scrum doesn’t measure you by the hours you logged, but by the tasks you accomplished. Who cares how long a task took if the result is the same'?

But the reality is that I am using a team that combines an external organisation's development members and our own organisation's business folk. The external folk cost money, they have to record actual hours spent in order to generate an invoice. Along with the other internal team members, we also need to record our time (and forward-looking estimated time) to be able to negotiate our internal availability with the rest of the business organisation. By necessity, our sprint planning includes at least a high-level view of hours and $ cost to know if we have sufficient funding available for the sprint.

Whilst I get that each PBI gets added into achieving the planned outcomes of a

sprint,

and that we are focused on delivering real outcomes, each outcome needs to still be supported by other activities including documentation, training, project management and other non-direct-development tasks.

Some of these tasks should / must be attached to the Jira issue / story, others are important across all stories / issues; but all of them need to be tracked and managed in some way.

Whilst poker planning gives a sense of complexity and an order of magnitude about 'getting to done', it does not account for non-development 'overhead' required for achieving the done-ness of a story.

I think what your reply says is to remove the sense of Project Management artefacts from the sprint board and move it to a separate project board. But that breaks the effective link between a story / issue and the non-development activities associated with getting it / them to done?

I feel like I'm swimming around in circles trying to 'fit' the need for PM artefacts that don't natively appear within SCRUM and am still not sure how to resolve this?

[Jack Brickey]

Indeed scrum can and often does apply to non-development activity. If you PM tasks are closely tied to a given development task then including them would make sense. Generally for me, the PM activity happens at the front end and I like to keep things separate. For example, I would have a board for the PM where any ‘feature’ went thru this process:

1. reviewed
2. accepted or rejected
3. defined (requirements)
4. Moved to ready for dev and prioritized
5. accepted for development (at which point it would appear in the development backlog scrum board where it was Ranked and ultimately moved to a sprint)

now or if I were to have PM activities associated directly with the dev tasks in a sprint then it would make sense to capture there. In the end it is a personal preference. What works for my team may not be best for your team.