ritcheymt wrote:In usergroup meeting last week I showed the whiteboards and sticky notes the standup team uses to prioritize enhancement requests and plan iteration development and resource allocation. Seeing the long list of open tasks, some usergroup attendees volunteered to take several tasks off the back of our employees. Thanks! This is how a wiki should work!
I proposed that we get this document online in a form where volunteers can see it and volunteer for tasks. I think everyone on the employee team agrees that this would help us develop the wiki faster.
I think that some of your tasks might not want to be public. Specifically, high priority security issues should probably not be posted on the wiki.
You also might think about hiding all current sprint tasks, so that a wiki user does not jump into an edit war with someone tasked with completing that task.
So I propose that you open the backlog generally, but mark the current sprint's tasks as completed at the beginning of the sprint. For the next sprint, I would make committed tasks read-only.
This would allow users to see items move into the sprints, and see their issue get prioritized and fixed, but not get users and employees tripping over each other.