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.
Related
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"
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 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
What do you defines as an impediment? I know that Scrum say that and impediment is something that stop the team from performing the best it can. So basically it can be everything? But where goes the magical line where it becomes and internal improvement?
For example. We want to have more realistic test data in our databases, is that internal improvement or impediment? We as a team could try to solve it in the sprint along with the other stories directly, or we could say that it's an internal improvement that needs to be a story and go into the product backlog.
As I see it we have three options:
1. Handle all internal improvements as stories in the backlog and make the PO prioritize them.
2. Work with them along regular stories in the sprint.
3. Big things goes in as stories and small stuffs we can do directly in the sprint without it effecting the velocity much.
How do you handle this? We need tips and ideas on how we can do this :)
What is an Impediment
An impediment is anything holding the team back. It's a very wide open category that can include things like:
physical hardware limitations
missing or poor tools
personal conflicts
missing skills on the team
missing personal skills
lack of influence or authority
illness
missing knowledge
We often focus on the obvious: tools and authority, but more often it's the intangible that holds a team back. Things like team cohesiveness, knowledge, and experience.
More realistic test data
Don't get caught up categorizing the improvement as internal vs impediment. Our goal is to embed improvement into the natural delivery process. For that reason, my first inclination would be to say all impediments and improvements should be done in the context of delivering. You want improvement to be reflected in the ability to deliver. We want our outcomes to reflect reality. Sometimes improvement efforts mean we temporarily lower velocity in the name of future increases. Sometimes we even permanently lower velocity in the name of quality.
I would suggest finding incremental ways you can get to your proposed end state and implement a little bit of it each time you touch that area, each sprint, and/or each time your prepare another test run (assuming it takes prep time - if not - fantastic!).
Improvements on Backlog
This is your choice and something you should discuss with your PO. Understand that while the PO wants high quality and improved output from sprints, the backlog is meant to represent valuable features/requirements from the user's perspective - not yours. For that reason, I would be hesitent to put improvement items on the backlog. You should ALWAYS be improving with each backlog item. Your PO may also balk at filling the backlog with things they feel should be done as part of normal delivery. Take it as a signal that this stuff is not directly valuable to the user, but a cost of delivering high quality value at a sustainable pace.
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.