Skip to main content

How to mention field position in agile ?

Last post 09:12 am February 7, 2017 by vishal Rajadhyaksha
7 replies
04:54 am February 3, 2017

The application I am working on involves three major workflow:

1. Create message

2. Edit existing message

3. Withdraw message

So, basically we need three buttons on Home screen for above mentioned workflows.

In agile, do we need to mention this requirement in the form of user story only? Can you please give example?


07:49 pm February 3, 2017

Remember that in Scrum, you don't *need* to write user stories at all. The Scrum Guide doesn't mention them.

Every Sprint must result in a potentially usable increment of value being delivered. That's where the agility is, not in writing stories. A useful increment might encompass one of the features you mention, or a combination of them, or a sub-flow of one which the Product Owner thinks is valuable.


11:42 am February 5, 2017

So how should I mention my requirement which I have given in first post ?..


06:18 pm February 5, 2017

> So how should I mention my requirement which I have given in first post ?..

From your reading of the Scrum Guide, do you think it might be a good idea to simply mention it in Product Backlog refinement, giving whatever information you have, and then allow the rest of the Scrum Team to provide their input?

Remember that refining Product Backlog items is a collaborative act, and an ongoing one, between the Product Owner who wants the value, and the Development Team who would deliver it. That's the most important thing.


05:27 am February 6, 2017

So you mean Graphical user interfaces such as buttons should be mentioned in product backlog and nowhere else?


05:45 am February 6, 2017

Okay...so after going through few online websites I got that you simply mention the requirements for buttons in prototype or wireframes. No need to mention in any document.

Also, in agile, wireframes or prototype is designed using pencil and paper instead of some tool because agile focuses on collaborative interaction so you expect inputs from client as well as your team. Hence , no time to use software.

Please correct me If I am wrong.


11:53 am February 6, 2017

The approach you have just described is certainly a more agile one than trying to write user stories by yourself.


09:12 am February 7, 2017

Thanks for your guidance.


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.