Author: Andrea Reese Hurst
At the request of an engineer who I wrote requirements for, I jotted down some tips for good requirements gathering in a software setting. Here they are, a bit tidied up:
Identify the end users, the project owners, and other stakeholders who influence the success or failure of this effort. Schedule time as soon as you can to talk with each of them – especially end users – about their role, their pain points, and their vision for the project. This focuses your efforts and helps get buy-in from all parties early. It dramatically reduces last-minute objections that come out of the blue to torpedo your schedule.
 
Have the end user walk you through their current process. Specifically, document:

1. where they get the information they need (such as systems, publications, and people)

2. what they do with that information in the course of their work (including what systems and tools they use)

3. what their outputs are, and

4. where or whom they send the outputs to.

Laying this out clearly may help you see a previously invisible solution – maybe they just need access to some useful reports instead of a whole new interface, or maybe there’s no real problem with the current method after all, or maybe the problem is much larger and requires interdepartmental cooperation to address. Regardless, it’s good information.
 
Document pain points without jumping to solutions. As your stakeholders review their process and pain points, they might propose specific solutions. Acknowledge and document all suggestions, but don’t commit to any one approach yet. As you build a more complete picture of the problem, your team can develop the best solution to address pain points systemically rather than patching together incompatible or costly feature requests.
Gather requirements iteratively. Start by roughing out objectives and requirements, and then get feedback and refine them until they’re ready for development. If you ask stakeholders up-front for permission to follow up, most will be happy to help. People generally love being asked their opinion. For complex projects, schedule a recurring meeting to run through follow-up questions regularly as you refine the project.
Don’t commit to schedules or features with the customer until the project manager and solution manager have nailed down the scope and prioritized the features. Actively manage customer expectations of what they’ll get, by following up on discussions of features by reminding them these are potential solutions that still need to be prioritized and discussed with developers for feasibility.
Talk over the prospective features with development leads to get a feel for feasibility and scope before you go very far down the road of writing up the requirements. They’re the ones who will be doing it, and they know better than anyone what their teams can do by when. Some people call this “T-shirt sizing” where features or user stories come in sizes XS, S, M, L, or XL.
Get the decision-makers’ priorities. Ask them what features are absolutely critical for operations to continue, and then go down the line to the nice-to-haves. One helpful set of categories for this is MoSCoW (Must, Should, Could, and Won’t). Make sure you know why they categorized each feature the way they did.
Author: Andrea Reese Hurst

Author: Andrea Reese Hurst
Coming from a waterfall development environment, I was used to polishing a requirements document to the nth degree before handing it off to development, but in an Agile environment, this put me behind schedule, and didn’t even make good user stories. Here are a few things I learned while working in Agile for a few years:

• Give the developer all the information they need to get a good start on the user story. The developer wants to sit down, plug away at a user story, and knock it out. You don’t have to be exhaustive, but give them enough to begin without contacting you first.

• Briefly summarize why you’re entering the ticket, whenever it’s not self-evident. When the dev knows your purpose, he or she may have a better solution. This is especially true of user stories that aren’t well-defined.

• Give the specifics up front if you have them. Don’t make the dev come back to you for stuff if you don’t have to.
  • • – Specify exact column names, field names, names of roles, and any other information the dev will need to finish it.
  • – When the ticket involves complex permissions, or a variety of data sources, attach a spreadsheet specifying precisely what those are. It may seem like excessive detail this early, but it’s not.

• Include a picture of new features. Attach a mockup of any new features if you care at all how they look (which is 98% of the time if it’s for a business user).

• Break out compound requirements. If the requirement has a bunch of subrequirements, create an epic with links to subsidiary user stories rather than one huge story with bullet points. This
  • – lets the dev take ownership of one subtask, mark it done, and move on, which is more Agile and – let’s face it – more rewarding than hacking away at one monstrous requirement for a month
  • – lets multiple devs chip away at it
  • – allows you to prioritize, comment on, add, or close out individual stories without affecting the other pieces
  • – lets you and the project manager track issue progress more granularly.

• • Make them aware of gaps. If you’re not sure of something but the requirements need to go out, add a comment specifying what information is missing (e.g., “Andrea needs to find out from Jeff whether we already have access to Table X,” or “Customer needs to finalize wording with Sales Department”) so the developer knows to come to you for an answer when he or she gets to that part.

• • Don’t repeat yourself. Give them less to sift through. For example, if the mockup covers the layout, don’t describe the layout – just refer to the attached mockup by its file name.

• • Ask for feedback on your first several requirements. When you’ve drafted your first batch of requirements, take them to the development lead and ask if these work, and whether you could make them more useful. Let them know you’re always open to feedback.

• Follow the item in the work tracking system. This helps you stay in the loop so you can report on the status of the ticket to your client, make sure development understood your requirement, and respond to comments by the devs or QA engineers.

Author: Andrea Reese Hurst

Author: Karen Stackhouse
I’m often asked about the difference between a Scrum Master, a Project Manager and Product Owner.  They all are very distinct roles and are interconnected and dependent on one other.
So, what’s the difference?  In Agile development there is typically a Product Owner and a Scrum Master.  Depending on the organization, a Project Manager may also be part of the overall team.
The Product Owner is responsible for the overall product development and its lifecycle.  They set the vision and the metrics for the product (through market analysis, control groups, etc.).  They also maintain and prioritize the Product Backlog (consisting of user stories) of features.
The Scrum Master is responsible for managing the work of the team developing the features.  They work with the delivery team to deliver features, monitor the team progress, work to remove impediments and protect the team from outside influences; they are responsible for the overall health (both progress and satisfaction) of the team.  They work closely with the team and the Product Owner to ensure the Development Backlog is groomed and is maintained to maintain project velocity and progress.
In general, the Product Owner maintains the vision of the product and the Scrum Master works to make sure the vision is met according to the Product Owner’s specifications.  In some organizations, a Project Manager is injected into the project team.  Their main responsibility is to oversee budget and timeline and work in cadence with the project team to make sure the project is delivered accordingly.  If the Scrum Master is tasked with monitoring budget and timeline, they take on the responsibility of the Project Manager; however their main task is to oversee the Development Backlog and the health of the team and report progress upward to Management.
A Project Manager maintains the budget and timeline of the project and reports status to management.  They also coordinate with other organizational project efforts to make sure that the organization as a whole is healthy from a strategic vision.

In general, the Product Owner maintains the vision of the product, the Scrum Master works to make sure the vision is met according to the Product Owner’s specifications, and the Project Manager is tasked with managing the budget and timeline and ensuring the company’s strategic vision is met.
Some organizations choose a hybrid of the Scrum Master and Project Manager roles.  If that is the case, the Scrum Master takes on the added responsibility of the budget and overall timeline.  This hybrid is one that is become more common as organizations streamline their staff and task them with greater overall knowledge of the organization’s vision and processes.  This doesn’t change the Scrum Master’s responsibility to maintain fluidity within the product and development environment and protect the team from outside influences.
As a consultant, I typically fill a hybrid role, since my clients require I manage the budget and the team on a daily basis.  I use the general tenants of Scrum (Daily Stand Up, Sprint Planning, Retrospecitves).  I also have the team participate in consistent backlog grooming where we review the stories, estimate them and add any information required for development and acceptance.  I have the added responsibility of overseeing the budget and overall timeline and reporting progress to management.  I may not be the Scrum Master in the traditional sense, but I’ve found with support from management and the important input and responsibility of the Product Owner, we can create success.
Author: Karen Stackhouse

Author: Mike Chatwin
I have heard horror stories from colleagues of daily scrum meetings that run over an hour…
STOP IT IMMEDIATELY! A daily meeting running this long becomes a roadblock to several of the basic principles of the Agile Manifesto (www.agilemanifesto.org):

– Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

– Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

– Simplicity–the art of maximizing the amount of work not done–is essential.

How can these principles be met, if the team is locked up for an hour EVERY DAY? It is the responsibility of the Scrum Master to assist the team in efficient delivery of product.  Start with the daily Scrum!
Cardinal Rules of an Effective Daily Scrum:
– The Scrum should start on time
– The Scrum should take NO MORE than 15 minutes.
– The Scrum is for each team member to answer “The Three Questions”

What did you accomplish yesterday

What will you accomplish today?

What issues are keeping you from delivering on your commitments?

– The Scrum is NOT to discuss technical details, administrative stuff or solutions. (Those are more efficiently handled off-line).
Remember, an effective Scrum Meeting is a SHORT meeting!  Minute details and follow-ups can be done without tying up the entire team!
Also, it is a good idea to conduct this meeting with everyone standing.  This encourages the team members to keep it brief!

Why are the “Three Questions” so important to a Scrum Meeting?

A Scrum Meeting is the opportunity for each team member to answer the “Three Questions” of Scrum:

What did you accomplish yesterday

What will you accomplish today?

What issues are keeping you from delivering on your commitments?

The three questions and the Scrum meeting are only partially about communicating status.  A good Scrum Master will already have a good idea of the status of his backlog.

The ceremony of the three questions is about making a commitment.

The team member is reporting what was accomplished the day before… then COMMITTING to the day’s activities. And declaring risks to meeting that commitment.  This public commitment establishes ownership over that particular user story.
Again, the Scrum Master should analyze progress on stories.  If a team member is spending an unexpected amount of time on a story, determine why.
It is actually MOST efficient to make this a ceremony.  ASK each team member the questions, and record their answers.  This cuts down on rambling.  Lengthy discussions should be deferred until after the scrum meeting.
When the meeting is over, the Scrum Master is responsible for:
– Removing barriers to the completion of stories.
– Analyzing progress.   If a team member has been working on the same issue for several days, investigate.

Was the size of the story underestimated?

Is there an impediment that the team member is trying to resolve alone?

– Follow up on any technical discussions (they were deferred until AFTER the Scrum Meeting.  Make sure they aren’t forgotten completely).
Scrum Masters, be mindful of the time spent in your Scrum meetings.  If they are consistently longer than 15 minutes, analyze and improve (a basic tenant of Agile!)   Don’t ACCEPT a long Scrum meeting!   Keep it under 15 minutes!
Author: Mike Chatwin