Every software development team needs to communicate with a variety of stakeholders, for multiple purposes and across many aspects of the project. Among the foundational steps is the ability to translate "customer needs" into accurate and actionable requirements. In this lesson we will discuss the inherent challenges within requirements elicitation and look at ways in which the initial steps of the software life-cycle process can be adapted to reduce unintended consequences.
You will begin using some tools to facilitate your internal team communications and capture your initial recommendations.
For your study of this topic, review these resources prior to class.
NOTE: In one place, the Creating user stories video makes an equivalence between the Definition of Done list and the Acceptance Criteria making it sound like these are the same thing. This is not the most common interpretation which is that these are two distinct lists each serving a different purpose. The Definition of Done is the same in most user stories and is a list of all the process steps that must be completed to finish development of the user story. The Acceptance Criteria are specific to each user story. The criteria are written in a specific format, and each one provides a description of one aspect of the required user story funtionality. Together, all the acceptance criteria should fully define the user story requirements.
Consider these links as reference material for deeper study.
As a first step, your group must assign a role of either customer or developer to each member. You are to role play throughout the elicitation process and in polishing the requirements for this activity. Assign at least half of the team to act as "customers". Secondly, based on your previous individual activity, decide as a group which elicitation technique and format you will use to document and stick to it. Capture your work in a group editable online document.
The following list of requirements are non-negotiable but you are to expand on the scope as you see fit to address the "users needs". Be sure to document any and all of your assumptions and use standard format to separately identify and document each requirement. Your goal is to capture all requirements for an MVP.
After you have produced the MVP list of requirements, revisit the scope and identify any possible flaws. Capture these together with the assumptions at the end of you shared document.
Finally, "step-back" and discuss the process that you followed in order to achieve this assignment. Document your answers to the following:
Teams should get into the habit of doing very quick standups when you meet to work on the project. This let's everyone know how well the team is moving toward the sprint goal and focus on identifying impediments and pairing members to work an impediment off-line. In retrospective discussions with teams in previous classes, the number one issue that team's say hindered their performance on term projects was a lack of communication within the team. Don't let your team fall prey to that by not communicating.
In-person standup meetings work the best. There will be some class sessions that may end a little before the end time. Your instructor will indicate that each team should do a standup meeting then. Your schedules might allow you to arrive 10 minutes before the class session starts and use that as a time for an in-person standup meeting also. You might also have work sessions where everyone is on an audio/video channel and you can do your standup synchronously, but not face-to-face.
Standups can also happen asynchronously in a virtual environment. The instructions you followed to create your team's Slack workspace have you create a #virtual_standups channel. Get into the habit of checking in on that channel on days when your team does not have an in-person or other synchronous standup meeting to provide your progress on Sprint work and see the progress others are making. In that channel, each of the members of our team can quickly answer the three standup questions:
You all do not have to checkin in the same time period. Each team member can when their schedule provides two or three minutes of time to do it.
When you hold an in-person or other synchronous standup meeting, one team member will make an entry in the #virtual_standups channel indicating when and where the meeting took place, and who participated in the meeting.
Remember that your instructor will be looking at your team's Slack workspace for indications of participation in project discussions. Your presence in the team's Slack workspace will be evidence of your participation and contributions to your team's project work. Little or no presence in the team's Slack workspace will be one indication of your lack of participation in the project work. It will be OK for you to occasionally miss a checkin but between in-person and synchronous standup meetings and checking in on your #virtual_standups channel you should be present at least four times a week.