This question came from a webinar I co-hosted for Management Concepts.
Read more at Management Concepts Blog:
This is a simple question for Agilista’s but an an appropriate question for those of you who are new to Agile.
For the purpose of the federal audience, I want to step back and define what a traditional set of requirements are. Typically, traditional requirements are text-based requirements such as a business requirement document or functional specifications. They typically describe in detail what the business is expecting the IT department or vendor to provide. There are other types of the requirements which are less text based such as Use Cases, Wireframes for screen designs, and workflow-type of requirements called UML. They are written at the beginning of the project, and they are at an exacting level of detail. Many Agile teams remain using these types of requirements especially if they are slowly transitioning to Agile.
User Stories take a very different, extremely simple, approach. In the most simplistic version, a User Story, which is an Agile business requirement, is captured on an index card. It is presented as a conversation between the user and the developer.
On the front of the card is
“As a <role>, I want <goal/desire> so that <benefit>“
or even more simply ….
“As a <role>, I want <goal/desire>“
Stakeholders write user stories. An important concept is that your project stakeholders write the user stories, not the developers. User stories are simple enough that people can learn to write them in a few minutes, so it makes sense that the domain experts (the users) write them. Some examples of user stories are:
- As an administrator, I want to be able to reset passwords for any user
- As customer, I want to be given alternatives if what I am searching for is not found
- As a customer, I want to be alerted if someone changes a file I created
- As a user, I want to search for my customers by their first and last names.
Remember non-functional requirements also. For example, as an end user, I want the application to work with IE, Firefox and Safari.
Another type of user story is called an Epic. Epics are large user stories, typically ones which are too big to implement in a single iteration and therefore they need to be disaggregated into smaller user stories at some point.
One of the key principles of Agile is maximizing the work “not done”. User stories are the embodiment of this principle. They tell the developer only what value the business user is looking for. By not going into excruciating detail and allowing the developer to determine a solution, there is less wasted development effort. A user story first goal is be complete enough for the development team to perform relative sizing, in other words, develop an estimate. If more detail is needed later, then the stakeholder needs to be available throughout the iteration or Sprint for further discussion.
User Story development can be as simple as what I’ve described if the organization is aligned for Scrum. I have included a link to a user story card template if you are interested in seeing one or using it for your team. Good luck, and be patient. As with any Agile method, be iterative and inspect and adapt your process until you are happy with the results.
About the author:
Dan Tousignant, PMP, PMI-ACP is a project manager on Agile projects. He provides Agile Coaching and Training for Management Concepts, Inc.
Are you a Project Manager in an Agency or Organization moving to Agile? Is there a role for you?
The typical Agile answer to most yes or no questions is “it depends.” (but my answer in this case is a resounding, YES!).
This post was originally on my blog on Management Concept Inc’s site:
Whether you work for the Federal Government or for private industry, you are probably wondering or even struggling with what your role will be as your organization moves to an Agile or Scrum environment. The Scrum purists are ardently against the idea of a project manager. They are in favor of a Scrum Master without any “command and control” bad habits, and yet the huge number of project managers applying for the PMI-ACPsmcertification would have you believe that project managers are actively involved in Agile.
I should note, that I am not a Scrum purist. My experience with Scrum is from the early days. I was hired in the Spring of 2000 as a project manager over a Scrum project. One of the founding fathers of the Agile Manifesto had just implemented Scrum at a large organization that was trying to rapidly deploy their web presence. I was a relatively new PMP, and I was asked to manage a software development team that had already begun using a Scrum methodology. Yes, its true, a project manager using Scrum – oh the horror of it all!
I can only tell you based on my personal experience since then, I have never had trouble finding work as a project manager on Agile Projects. The only caveat, and this is where I completely align with the Agile community, is project managers should not be telling people what to do, they should be facilitating.
As a project manager on Agile projects I have been successful in the role of Scrum Master and Product Owner. Both of those roles require similar competencies as the project manager role in a non-Agile environment.
I never give up my title of project manager, because I believe my training and experience as a project manager are what makes me effective in either of these roles. As a consultant, I have always understood the need to modify my role for a particular client or project and Agile projects are no different. Agilistas love the term, “Adapt or Die”, I think this holds true for project managers as well. Our industry is constantly changing, and we have to be flexible and change with it, but we don’t have to give up being a project manager, we just have to know which of our many hats that we need to wear when working on an Agile project.
About the author, Dan Tousignant, PMP, PMI-ACP, PSM I, CSP
Dan is a lifelong project manager and trainer with extensive experience in managing software development projects. Based upon his experience, he has adopted both Agile as the primary method for developing and implementing software. He is passionate about the leadership emerging from self-organizing teams.
Dan has over 20 years of experience providing world class project management for strategic projects, direct P& L experience managing up to 50 million dollar software development project budgets, experience managing multi-million dollar outsourced software development efforts and strong, demonstrated, results-driven leadership skills including ability to communicate a clear vision, build strong teams, and drive necessary change within organizations.
Dan holds a Bachelor of Science majoring in Industrial Engineering from the University of Massachusetts, Amherst and is a Certified Project Management Professional, Professional Scrum Master, PMI Agile Certified Practitioner and Certified Scrum Professional and is the owner of Cape Project Management, Inc.
Cape Project Management, Inc.