Recently I have been challenged by coming into a new startup which is still finding it’s way with agile and just work item management. Over the years, I have managed and lead many different teams and below is the outline that I have found to work in my experiences. That being said though, remember that agile is also about being nimble and fulling adopting the phrase inspect and adapt.
Work Item Definitions:
Feature – A collection of backlog items that are related. This is useful to ensure that all of the ancillary (ie the version 1.1 stuff) is still tracked along with the main work and can be fit in along the way instead of having those “we meant to do that” moments.
User Story – The specifics of the work to be done which includes details, and supporting materials such as any mock-ups, whiteboards, so forth.
Task – The individual work with an estimate. An example would be to implement a DB schema change, and updates to the Business logic layer.
User Story States:
New – This is a new item that needs to be vetted by IT and the business. In other words the general catch all that IT and business stakeholders can log work.
Approved – Has been vetted, technical details and acceptance criteria can be flushed out on what is involved before the sprint planning meeting.
Committed – Approved and scheduled
Dev In Progress – Work has begun
QA In Progress – Quality Assurance staff has begun testing
Deploy Pending – Work is completed, should be queued for next release
Completed – Released and available to the user base
Backlog grooming – Meeting where IT meets with the business and discusses stories that are in the “New” state. Discuss if needed for either technical or business reasons and does a high level discussion on what is involved. Attendees: IT manager and business stakeholders.
Pointing / Planning Poker – This meeting would be where the dev team looked at the approved work, and assigns a level of complexity to the effort. Keep in mind this is not a tasking exercise, which is where the work is decomposed and hour estimates are assigned, but rather a way to look at the effort in a somewhat quick matter and give it a rating compared to similar work. The pointing uses the Fibonacci sequence and typically what I have found is that anything with a 13 or higher is most likely too much work and should be decomposed more at that story level. Attendees: Development team and architecture
Prioritization – IT and the business meet to discuss prioritize and rank the features and stories that have been approved. Commonly, this is done during the grooming as well, but depends on the team and their backlog size.
Sprint Planning – The team meets and discusses the user stories that are approved in priority order, tasks them out and estimates. Should expect the first couple meetings to be a bit slower until you get into a groove. I have also seen in the past where you essentially budget system improvement items and then business feature work. For instance, you may say that IT require 15% for system improvement so that they can allocate the time to improve the system, logging, or support tools for example. Attendees: Development team, business stakeholder, architecture
Sprint Retrospect – Team meeting to discuss what went wrong in the previous sprint, how can we improve, and what are the action items and owners of those leaving the meeting. Attendees: Development team and architecture. In my opinion, this is one of the most important meetings for continual improvement.