Does your agile team put requests in your backlog BEFORE there are supporting requirements ?

[Randall Hoff]

Should stories/tasks be placed in the backlog unless there are at least business requirements?

If business and technical requirements are insufficient to work the issue, should it be there?

If the story suddenly gets priority, I see insufficient time to develop good requirements for the oncoming sprint.    

[John Funk · Accepted solution]

Hi Randall,

The way we operate is that all ideas/requests/stories/tasks, etc. get created and placed in the backlog. That gives us a central location and visibility into all requested/desired work. 

As a part of refining (use whatever term you like) the backlog, all requirements are placed on the issue that was discussed (just the ones that we can work in the next week or so). 

Then we pull the card to our first column on the board which we call Options (the status behind the scenes is really Backlog Pullable). This indicates that the issue has everything it needs for at least the first step to be done (hopefully more!). 

When the card leaves the Options (first) column, we consider that our Commitment point. 

Caveat is that we due Kanban and not Scrum. So we an replenish from the Backlog whenever needed. However, that cadence is usually on a weekly basis for most of our teams. 

Hope that helps!

[Randall Hoff]

Pullable status is a solid solution.     And I agree about capturing everything too----

We are wrestling with getting the details in time for sprints.   Some sudden priorities do not have what's needed to begin work/development.   We may need a separate status to identify what is ready to work.....and what is not because some bare minimal definition is not there.   

Thanks!   

[John Funk]

Oddly enough, some of our teams have implemented what we call a "triage" process. We added three new statuses between Backlog and Backlog Pullable. They are Reviewed - Not Ready, Reviewed - Incomplete, Reviewed - Ready. 

So when an issue comes into the backlog, it stays until it can be reviewed. Once reviewed, it moves into one of the three new statues. Not ready meaning the requester provided everything but we are not ready to move on it yet. Incomplete meaning there is still missing information in order to start. And Ready meaning, well, Ready.  :-)

You could actually interchange the Reviewed - Ready with Backlog Pullable if you want. We left both just to not interfere with the integration between projects that do not use the triage process yet. 

[Bill Sheboy]

Hi @Randall Hoff 

When I think of supporting the work of an enterprise as a series of interconnected workflows, it may make sense to have a board for the delivery team and another board (in the same project) as the upstream discovery steps.

The discovery board could be Kanban (or Scrum) and the delivery board Scrum or Kanban.  You can choose whatever best matches your workflow for opportunity assessment, discovery, delivery, release, and sustainment of valuable features.

Best regards,

Bill

[Dharma Ramos]

When I was an SM, everything went in bottom of backlog for transparency, but then we created a pre-groom sprint for refining upcoming work. Once refined and pointed it was added to an upcoming sprint.