This week, we learned about software requirements in the context of Agile, how they are created and changed throughout the software life cycle, and methods of tracking them. In Agile or behavior-driven design, requirements take the form of user stories, which are basic high level statements, often short, that describe functions in a program. User stories are accessible to both stakeholders and developers and can theoretically change and update often due to continual conversations between stakeholders and developers.
A acronym to follow for writing good user stories is SMART, which stands for:
Specific - User stories should state application/program behaviors clearly without any vagueness.
Measurable - Each user story should be testable, with expected outputs for a given set of inputs. These can also be performance requirements as well.
Achievable - Ideally, each user story should be completed in one Agile sprint. If not, stories should be split into smaller ones.
Relevant - User stories shall have value to at least one or more stakeholders.
Timeboxed - If a story cannot be completed in one iteration, it should either be sidelined, split into smaller stories, or brought up in a discussion with stakeholders to focus on the highest value part of it, given remaining budget and/or time constraints.
At my job, we use Atlassian's Jira, which is a tool very similar in functionality and design to Pivotal Tracker to keep track of bugs found in software builds, along with the usual stories/epics/kanban boards present across different teams.
A acronym to follow for writing good user stories is SMART, which stands for:
Specific - User stories should state application/program behaviors clearly without any vagueness.
Measurable - Each user story should be testable, with expected outputs for a given set of inputs. These can also be performance requirements as well.
Achievable - Ideally, each user story should be completed in one Agile sprint. If not, stories should be split into smaller ones.
Relevant - User stories shall have value to at least one or more stakeholders.
Timeboxed - If a story cannot be completed in one iteration, it should either be sidelined, split into smaller stories, or brought up in a discussion with stakeholders to focus on the highest value part of it, given remaining budget and/or time constraints.
At my job, we use Atlassian's Jira, which is a tool very similar in functionality and design to Pivotal Tracker to keep track of bugs found in software builds, along with the usual stories/epics/kanban boards present across different teams.
Comments
Post a Comment