In our last blog post, we talked a little bit about how we started to use the Scrum methodology to manage all of the projects that go into supporting policyIQ. We found ourselves in need of a tool, and set about using policyIQ to manage our new Scrum process.
Scrum in policyIQ for policyIQ
We can’t tell you what the best policyIQ configuration will be for managing the Scrum methodology for your business. Every team is going to be different. But we’re happy to tell you a little more about what we’re doing.
I mentioned in the last blog post that we started with user stories and then we went back to goals. Essentially, we currently have two primary Templates that are a part of our Scrum process.
- Goals
- User Stories
On our Goal templates, we capture the following:
- Description of Goal
- Area of the business (sales, marketing, product, support, etc)
- Priority
Each Goal is linked to User Stories that will support the goal. The fields here are much more detailed, and include:
- User Story Statement
- Business Value (or “Impact”)
- Effort
- Status
- Blocked By
- Currently Worked On By
We meet bi-weekly to review our last sprint – were there items that didn’t get finished? Why? – and to plan for our next sprint. As we plan, we move User Stories from the Backlog into individual sprint folders. (If something doesn’t get finished in a single sprint, we keep it in both the older and the newer sprint folders. It’s a lesson learned for us that we planned imperfectly – either we didn’t break our user story down into enough detail or there was a block that we couldn’t overcome in the given sprint.)
And of course, we use the policyIQ reports to plan, update our sprint items and to evaluate our progress. For the purposes of our scrum process, I personally almost never find myself in Create And Edit – but rather stick to the reports to take care of all of my updates and planning.
Flexibility? Yeah, we’re gonna need that.
We find ourselves telling clients frequently that one of the benefits that policyIQ brings to the table is the flexibility to change the configuration or the process if you find that something isn’t quite working for you. In our last blog post you read about how we ended up going back and changing the way we set priorities a bit, by going back to high level goals to prioritize. That doesn’t really tell the whole story – as the truth is that we’ve really gone back and revisited the process with almost every sprint to make small adjustments. New fields, new values, new Folders and new Templates. Lucky for us, policyIQ has allowed us to do that without having to make any significant changes to the original documentation.
Are you using Agile or Scrum in your daily work? We’d love to chat and learn what best practices you’ve found – and share some of our lessons learned. Of course, if you are interested in using policyIQ to manage your projects, let us know and we’d be happy to show you more of what we’ve done!
Pingback: Using Scrum to manage policyIQ (Part 1 of 2) | policyIQ Blog