Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
I'm just about to get to know Taiga.io which is a project management platform and provides a scrum task-board as well as a kanban user story board.
However: Since it seems to be very common to track the "tasks" of an sprint on the task board if using scrum.
If using kanban, you can track the userstories on the board and tasks are nested within the US and not pinned at a board as well - so there is no visual "movement" of the concrete working tasks as i understand.
Im now wondering if it is okay to just write user stories like tasks as the example of taiga.io shows:
Kanban us-board example
Scrum task-board example
(the user story ist not in the format like "As a , I want so that " but in a task description like "develop filereader" or "implement the db-sheme")
I would say that it's better not use user story (US) as task, and vice versa.
The reason is that US is usually used to describe the requirement. It's supposed to show the value to developers and answer the "WHY" question. So the format of US is like this: "As a ... I want ... so that ...".
On the other hand, task is usually used to answer the "HOW" question. When we look at a task we should be able to know what exactly to do. However it's not easy to see the real value from a single task. For example the value or benefit of "implement the db-sheme".
The Kanban and Scrum examples you showed illustrated the difference pretty well. For Scrum a US is something creates real customer value. Team uses tasks to make it happen. For Kanban it's more like a production line. The input for the team is usually already something doable, i.e., a concrete task. Therefor US is not that useful in Kanban.
Hope I answered you question.
You can write user stories as tasks, cause sometimes is needed for planning a technical implementation.
I dont know Taiga.io but, for example, in Attlasian Jira, you can create a US "As a user I want to send an email", which could have a subtask called "Create service for sending emails"
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I'm reorganizing my agile board on youtrack and am trying to conform to the industry best practices however I would much rather call an epic
"User Profile"
as opposed to
"A users can view their own and other users information and content on their user profile"
if I can get away with it.
I'm going to be applying for jobs soon so theres a chance someone might look at what I've done and I just want to make sure I don't look bad because of something like this.
To further clarify how I view each "Type" of issue (to make sure I'm understanding them correctly)
Epic - User Profile (brief description)
Feature - User Feed (detailed description)
Task - A user may like items in the feed
At the time of writing the epic stories, probably you don't have the same clarity level on what the customer really want.
So the epic title might be "User Profile" while later on when you start creating the user stories; the user story title "As user I want to be able to update my profile so that I can add avatar".
The title of an epic should be 'fit for purpose'. What that purpose is depends on how you are using them.
For example, say you were the only person who had visibility of the epics. In that case the epic title should be something that made sense to you. If, however, the epic was visible widely across business users then it would make sense to use an epic title that means the most to them.
There isn't really a 'best practice' when it comes to this kind of thing as agile approaches vary so much. Really it is about finding a solution that works well for your particular organisation and if it doesn't work well, adapting it to be better.
I would suggest the only situation you absolutely want to avoid is having epic titles that are meaningful to the delivery team, but not understood by the business users.
There is really no logical difference between an epic and a story; the distinction is one of scale. In fact, it is often the case that a story becomes an epic when the team estimates it to be relatively large.
We find it really easier to go through the product backlog items, specially when we are trying to rank them by showing a title which sum-up the main purpose behind the user story and if more details is needed then we dig into it to check the whole user story with it is acceptance criteria.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
I'm starting with Scrum. I have read about it but as a newbie I feel uncomfortable about a lot of things.
These days my team is starting the creation of a new game. We know the key elements of the game but we don't really know how they will really work. I would like the team to spend 1 or 2 weeks brainstorming and defining how the elements work. As an example one of the elements could be a grid of pieces where user clicks the pieces to destroy them.
Can this be converted into a user story or this is not the kind of thing that is converted into a user story? I was thinking about writing the user story this way: "As a player I would like to know what am I able to do when I interact with the grid of pieces". With this requirement I could justify the time spent in the design stage of this element.
I know a user story is something that the product owner adds to the backlog to provide some value to the project. For me in the design stage this would provide value because stake holders would know exactly how things work before starting real development.
Thanks in advance.
A user story should represent value to an actual user, not just a part of the development process. Start with a story like "Player plays the game for a few turns" or just "Player moves a piece on the board" or whatever you think will fit in to one sprint. Include in your estimation the time needed for all team members, designers and developers, to contribute. When you've implemented that story you'll have something a real end user will care about. It will be terrible, since you're just getting started, but you can write more stories to address that in later sprints.
It's important to keep in mind that stories are "a reminder for a conversation" and that the product backlog is not static, but evolving over time.
Let's say you start with something relatively imprecise as "player can destroy pieces placed on a grid." No details as to what that means yet.
When you arrive at the Sprint Planning meeting, the Product Owner indicates that this is the highest priority item, and everyone agrees that the Sprint Goal will be to figure out different ways to destroy pieces. You could proceed two ways here, depending on how much you know about destroying pieces.
If you have some ideas on how that could be accomplished, you could have a quick brainstorming session during the meeting. Let's say that, as a result, you identify 3 different ways in which that could be done. The original story is then split in 3 pieces, and then the team needs to decide how many of those they could implement during the sprint. Something important to realize here is that you can consider this early implementation as an experiment that will provide you later with more information to further refine the ideas.
If you have no clue about how this could be done, you could add a "spike" to the sprint. A spike is a time-boxed experiment designed to gather information to implement another story. So in essence, you're scheduling research time and deferring implementation for later, but the research is time-boxed and expected to provide implementation options.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
My team have recently gone to sprints and we are going through breaking down our user stories into tasks. What is the best practice in breaking down the user stories?
Should each task include developing, design, testing, and so forth? Or can the tasks be individually broken out? If so, should the tasks that aren't testing related just go straight to done and skip "Verify" or "To Test" column in the workflow?
From what I've read online it seems there is no 'set' way and people do it differently. I'm curious if people have had problems with their way of doing it.
Any help would be useful!
What is the best practice in breaking down the user stories?
Splitting user stories: the hamburger method
Elephant carpaccio
Should each task include developing, design, testing, and so forth?
As you wish. Maybe, you can test feature, not a task. But testing of small peaces (task) is easier, than whole feature (if it possible). BUT sprint product should be tested as well.
+1 for the Elephant Carpaccio :-)
The goal is to understand the power of thin and vertical incremental developments :
Thin : the smallest code is written, the less code have to be changed for future stories
Vertical : each story should change any part of the n-tier
architecture
code (presentation, logic, data), so that each story delivers
immediate business value
I facilitated it and met his creator (Alistair Cockburn). This game/exercise is really interesting for teams facing customers with frequent change needs and small cash funds.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
Referring to this buddy question, I want to know how one can manage specs in Scrum process ? I'm facing this problem while assigning tasks to my team for the sprint. Needless to say - I'm new to Agile/Scrum.
Currently, we are using our own specs sheet to map StoryId to SpecId and vice versa. I'm getting the felling that Scrum is more about project management [getting things done on time] and you need a seperate process to manage specs and requirements.
How do we manage specs in a Scrum process ?
The short answer is, you don't.
The important question to ask yourself when writing these specs, is why do we do them? What is the value in the spec?
The value in the spec usually comes in communicating the ideas of the business with the development team. Scrum is designed to bring the business (in the form of the Product Owner) to the development team. By interacting with the team frequently (remember, individuals and interactions over processes and tools), and by seeing working software frequently, the business can work hand in hand with developers to produce software that solves business problems better than by trying to spec out the whole thing before you get to try it out.
This is how Agile projects do a better job of delivering the product the business wants instead of the product they requested.
That said, there are certain base criteria that need to be met. We can test for this, and as with any good tests, we can automate it.
Have a look at BDD and Cucumber. In addition to your User Story, it's good to have a basic set of conditions of satisfaction, preferably in the "Give/When/Then" format. These conditions are the minimum set of criteria for the story to be accepted as complete.
For example, "Given I am logged in, when I log out, then I am taken back to the home page".
If you're going to have acceptance criteria, you're going to want to automate it. The worst part of most specifications is they often end up out of date and collecting dust when the project is complete.
Also, you shouldn't be assigning tasks to the team. Scrum teams are self organizing and anyone should be able to grab any task they feel they can work on while respecting the priority of the stories. Swarming is a big part of the performance benefits of Scrum.
You may want to consider bringing in an outside coach to assist with your transition.
I think that the easiest way is to make the specifications a part of the user stories within the tasks, themselves. Clearly list the acceptance criteria in each one (or if your issue tracking software allows you, create them as first class work item types). Let the issue in whatever you use for work item tracking become the living document.
There are drawbacks, such as finding related issues as specs change over time, but this can usually be managed in the work item tracking tooling, assuming your can relate issues to each other.
The way that we do it is that we (actually a BA, not the developers) creates a sign-off deck for the product owner to review and we collaboratively create tasks off of that. If we cannot create a task, or there are open questions, we will go back to the product owner with those questions and update the deck. All of our decks are organized (in SharePoint) so that we can easily find them in the future.
For me the specs is in the user stories. We define the specs and the tasks duing out initial scrum meeting along with the product owner. The specs and tasks are just for the life time of the scrum iteration as everything might change in the next iteration(in the worst case but there will definitively be changes).
We usually keep track of the specifications and task on a spreadsheet just so that everybody know what they are working on. I have also tried a few software to do this and one of the most interesting ones I have come across is from [VersionOne][1] and also from [Rally][2].
But I still find that using a simple spreadsheet is the fastest and simplest solution.
As I understand SCRUM, it does not take care about specs management. You have to broke/map your specs or specs changes to stories and tasks separately. But you can have a task for this :).
There is a real tension between Scrum and other agile dev methodologies and spec writing. I think there are two big points of tension:
Because agile says everything should
be on an index card, that means you
have to have stuff planned out
enough to fit on an index card.
(E.g. you have to know how it's all
going to work.)
Some things don't make sense in
isolation (what's the use of an
upload file page without a manage
uploaded files page, for instance.)
You don't have to design the whole app all at once, but you have to have a vision of the whole app. Then, especially if you have a separation of designers and programmers, you do functional design for a sprint-sized chunk at a time. Those designs then have to be broken down to story-sized chunks.
This is a lot of up front functional design, and I think that's overlooked in a lot of the talk about agile methodologies. Perhaps some shops have the devs do more of the design. Also, I think it's a lot easier to use scrum/agile for making changes/bug fixes to existing apps rather than building new ones.
The thing I've found most helpful is to fight back on story size. A lot of organizations have gone crazy, saying stories need to be only a few hours. The original scrum book says 16 hours, I think, which is often large enough to fit an entire screen of a web app. So "implement manage my account" could be a story (as opposed to the hundreds-of-tiny-stories approach of "implement username", "implement password" etc.) Then reference your design doc for "Manage My Account" and make sure to have word-perfect screenshots/prototype/mockup so the dev can look at them and copy/paste the text directly into the code they're writing, and they know for sure which fields need to be there (or which links, or which pictures, or whatever).
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
When designing a back-end system, what granularity do you normally give your stories and tasks?
Most examples of creating stories and tasks usually center around a GUI application with the story being something the user can do (e.g. search for a book by the ISBN) and each task centered around enabling this GUI feature.
When designing a back-end system, i.e. one that doesn't have a user interface but is just a bunch of services talking to databases, middleware, etc. how do you come up with tasks and stories?
Basically, I try to keep the size of my User Stories in the area of 1 to 10 man-days to complete. That keeps me from passing what Mike Cohn calls "Epics" or "Themes" as user stories to the developers, and on the other size stopping my user-stories to be so specific as to imply the solution (they should be describing the problem, not how it should be solved).
As far as content goes, I make sure that my stories contain only business value - it never describes how I (should) satisfy the demand, nor does it "require" non-user-domain knowledge to understand.
Good example: As a content manager, I want all users to have to log in before writing a talk-back, in order to deny them the ability to spam.
Bad example: Add captcha to the web site.
Tasks, on the other hand, are steps towards solving the solution - they describe components & functionality that need to be added / modified. This is where an "Add Captcha" solution comes in. As far as size goes, I try to have each task's size be between 1/2 a day and 2-3 days of work.
Tasks also include a set of standard tasks that apply to each and every feature / requirement / problem / bug, such as:
Document
Write Test Cases
Manual Test
Write automated functional tests
etc.
Hope this helps,
Assaf.
As long as you have users, user stories can be around things users can do. If you are providing an API for other developers, then they are your users. Things will get more technical at that point (i.e. User can update Employee records)
I base the stories on the public interface of the classes. For task granularity I shoot for work effort of half a day to two days.
A user/ actor can be a system, not necessarily a person. Your services will have an API, expected input and results and a service level agreements (non-functional requirements). All of those can be specified in the story card.
Most importantly, your story card should specify acceptance criteria. Accpetance criteria will help drive the developers Test Deiven Development Unit Tests, the automated functional tests and the automated performance tests. If the acceptance criteria is meet, the card is accepted and approved by the product owner.