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.
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 3 years ago.
Improve this question
Just had a quick question about Agile Development in terms of number of assigned user stories - per developer - in a sprint...
The gist is this: in a 10 day sprint, I had 2 stories that were assigned to me. The stories were very much related, and the second story clearly piggy-backed off of the first.
In Agile Development, is it acceptable to have worked on the initiative / acceptance criteria of both stories in one branch, and have the logic for both stories pushed up for a pull request / code review in that same branch.
The 2 user stories do have their own individual story numbers in our sprint management software. The first story was essentially rendering a component with 2 links, and the second story was making those links either go to a specific route (condition 1), otherwise they are each to open up a specific modal (condition 2).
During my code review, one of the devs asked why I did this, and suggested I should have waited for the first story to be not only code review approved, but accepted by QA before even beginning to work on the second story, saying that I added unneeded complexity for QA, and delayed the chances of the stories being accepted in the current sprint.
My argument was that (besides the constant and unnecessarily long time it takes for the code review), it did not make sense to finish the first story, then sit around and wait for it to be accepted before beginning the development on the second, ESPECIALLY due to the simplicity of it.
The flip side, had I started developing the second story, there would have either been unnecessary duplicate code (to render the necessary component from the first story) to test the new logic, or lots of going back-and-forth between branch-1, branch-2, and develop; not to mention using git rebase (which I'm down with, just sayin) on each branch (git pull new changes into develop, run git rebase develop on branch-1, then run git rebase branch-1 on branch-2. Just seems convoluted)
To be more efficient, and because of the minor criteria of the second story, I did all of the coding efforts in a single feature branch.
Whew! This was far more long-winded than I intended; sorry about that...
TL;DR -- is it ok for a developer to work on more than one separate user stories at the same time during a sprint, in a single feature branch? So long as they are very closely related and piggy-back off of each other..?
It sounds as if the user stories were mis-defined in the first place: From the user's perspective, what's the point in having a link in the UI that does not point anywhere? This is the situation you would have ended up with if your story1 got implemented without story2. I.e. what you refer to as user stories are not in fact user stories, but two tasks that belong to a single user story. To resolve the situation, this should be reflected in the management software.
But more generally, after the sprint planning meeting, there should be no questions left open regarding who does work on what tasks.
Answering your question, in general of course it is ok to work on more than one user story, but inside the team it should be clear to everyone who does what before one starts the work, and the general organisational conditions (QA of user stories, in your case) should be taken into account. Communication is key. If you think the user stories should be structured differently or some things do not make sense in isolation, let the others know about your opinion before you start working on it. The sprint planning meeting is the best time for this kind of discussions, but your scrum master should always be open to discuss. This way of handling stuff should avoid surprises for your teammates.
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
We have a project which is going to last approximately 5 sprints.
The project involves a number of user stories, each story involving work by different developers: Web (AngularJS & ASP.NET MVC) and CRM (Dynamics). It is therefore 'Vertically Split'.
Each user story builds on the last: more fields being added to UI and more fields having to be picked up by CRM workflows. Testing each user story therefore requires re-visiting the user interface and back-end a number of times and testing the new fields just added.
Unusually, we have been asked to handle the sprint with 2 different types of task: the user story is put on one post it note, and the story has been further decomposed into the activities required by each developer (UI / CRM). As a result we are actually ending up with two burn downs: this is something which I don't understand considering that we haven't provided estimates for the individual tasks.
I understand that splitting user stories vertically means that you are always going to deliver something useful, but I can't help but think this is not always going to be the most efficient way of delivering the project, especially when you consider you're revisiting the same parts of the application again and again.
Is there any scenario where a horizontal splitting is acceptable in scrum agile, as in our case it would allow a CRM developer to implement their work in a separate user story? After all, if it's early on in the sprint, the risks of not implementing a feature in the developers respective layer is quite small. Furthermore, there wouldn't be a need to decompose the user story into further 'tasks'.
By decomposing tasks into horizontal (architectural) tasks in this case, we can make the UI changes in a few days and then get the CRM developer to pick up the data that we send across in a separate story. I think this would also make it far easier to test, because you are testing each complete 'feature' in it's respective environment rather than building it up across several user stories....
Obviously if you are a full stack developer it's a lot easier to achieve vertical splitting,. But it's not the case with this project....
What is the suggested approach where you have an application which is consistently increasing the number of fields / UI? Is horizontal splitting of tasks ever permitted in agile or is it always a no-no?
I'm not sure that even if you split the tasks horizontally you will achieve what you'd like. Let's take an extreme example where UI developer completes 100% of his tasks while CRM developer completes none of his.
Will there be any feature released (or any user story fulfilled)? I guess not.
Therefore, I would suggest to address the UI and CRM developers as one unit (with common burndown) and split the tasks internally between them.
Preferably, they will work in similar tempo so they can provide each other with tasks to complete.
Also, this cooperation can be a good thing as both UI and CRM developers will feel more commitment to the project since they have a common goal and measured as a common unit.
Hope it sounds reasonble and helps you to make a decision.
This is where the concept of swarming comes in. Assuming your scrum team consists of members with technical competencies that cover all aspects of the user story (e.g. UI, CRM, DB, etc), then your scrum team can swarm the first user story working together to complete all aspects at the same time. Assuming you have a tester embedded on your team, they can be writing test cases for it at the same time as well. In a day or two that story is done and you have something fully functional and demonstrable to your product owner/stakeholder. Then the team swarms the next user story. It takes time for a team to get into a rhythm to be able to do this effectively, about 6-12 months in my experience for a team without prior experience working this way to do so.
Also by doing the entire vertical path up front you learn what is needed early and can make changes quickly before there is a lot of code to refactor. If you do an entire layer first and then the next layer, besides not being able to test that first layer yet, you end up finding things when implementing the next layer that will cause you to have to go back and redo the first layer. This results in extra work or creates non-maintainable code as things are hacked in to meet deadlines.
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
We are just beginning to move from Waterfall to Agile. One of the few complaints about our new process is that our iteration planning meetings are taking too long, mostly because we are writing our story cards in the meeting itself, which was how the process was described to me.
One suggestion was that we write the story cards ahead of the meeting and ask everyone to review them before they come to the meeting as a potential time saver.
Is there an advantage to doing the stories during the meeting, vs. writing the story cards ahead of time and asking people to review them ahead of time, potentially saving everyone some time?
This is probably not an ideal question to ask as there's no real definitive answer. Responses are likely to be subjective.
Relating to my own experience, our team tends to get Stakeholders and Product Owners to add User stories in an adhoc fashion during our sprints to a projects product backlog (we work on a web application and are user driven in terms of functionality - we do have a roadmap, but we also adapt to feedback etc).
That way, when it comes time to do iteration planning we have a brief Product planning meeting with Stakeholders, Product Owner and project leads to discuss priority and adjust User Stories on our product backlog.
Once that's done, there's a subsequent Sprint Planning session with project teams that pluck off User Stories to work on in the sprint (picking off enough User Stories that we feel can be realistically achieved when gauged against our established velocity).
I'm sure other people do it differently, the key thing is to find something that works for you and your team.
which was how the process was described to me
You identified a problem in your process (too long planning meeting) and found out the root cause for it (writing story cards). The most sensible and agile thing to do is probably not to stick to "how the process was described" but to adapt accordingly, which means creating the cards in advance.
That said, from my personal experience, the sooner user stories are presented by the Product Owner to the team the better. Sprint Planning will probably be when story estimates are refined and little details are tackled, but it's generally better if the team did at least some exploration and estimation ahead and don't arrive at the meeting completely ignorant.
One of the most important purposes of User Stories is to serve as a conversation starter among developers and stakeholders. Based on my experience, it can save a lot of time to have one or two people review all of the existing requirements or requests and translate them into user stories.
But it is vital that the story cards get discussed, and that should take considerable time. Even though it seems like a lot of time that could be better spent on development, the reality is that, without discussion, development can easily go in the wrong direction. Asking people to review the cards ahead of the meeting often does not work - if they don't want to take time to discuss the cards during the meeting, they probably won't review the cards on their own time.
My advice: ask two people to work together on writing the user stories ahead of the meeting, but use the meeting to review and discuss each card.
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's a good way to capture user stories when you have features that are common across multiple UI modes?
For example, imagine a commercial flight information system, something someone might use to answer the question "When is flight UA211 expected to land?"
As is often the case, the feature of providing schedule information is common underlying functionality, even though you might ask for it via a desktop web browser, a mobile browser (where you want to apply different style to make it more usable), and maybe even via SMS shortcodes.
Now, that certainly could be a single user story ("As someone meeting a traveller, I want to see flight arrival information so that I can be at the airport on time"). But that seems wrong (and would probably be an epic story, anyway).
You can make it separate user stories ("As a desktop user...", "As a smartphone user...", etc), which I've done in the past, and the team just knows to estimate the first one to include all of functionality, and the subsequent ones to estimate only UI implementation.
A third option is to make the underlying functionality a story isolated from the presentation layer, and then have UI stories: "As a flight info system front end, I want to get flight status information so that I can present it to the user", "As a desktop user, I want to see flight arrival... etc". But that seems artificial.
Thoughts?
dwh
I think the problem is that you are trying to tie the UI functionality to the backend too tightly.
For example, if you break it into a simple story:
A user may want to know the flight status given the flight number.
OK, now, given that you implement that, now you can look at which platforms will be calling this, as, one part of agile is not to over-develop, but in this case, if you have a business need to support mobile and desktop devices, then you should look at implementing this as a REST service, since that is the simplest solution for both to work with.
So the REST service solves the first story above.
Now, you will find that there are other specifics for each platform. For example, is there something on the phone that may already have the information, for example, did the traveller go to a trip site and already enter his info, then you may want to go there, assuming that the traveller is in the users contacts.
Or, if the user is just going to enter a flight number and that is it, then why not just do it as a webpage, as that is the simplest approach that supports both concepts. Then, if you have a url that supports GET, and outputs as HTML then you can easily display.
So, my first story was too simple, you may want to consider whether it is possible to return different types of data, so a user may want to have HTML, PDF, json or xml, but for each of these there should be a business need.
Unfortunately it is hard to answer your question as there are too many unknowns, which is why you are having a difficult time. If you ask the wrong question then you do have an epic, but if you can just break it down to a few simple stories then it becomes much easier to solve.
I would recommend the second option.
As you suggested, the first sounds like too much for a single story, and a story should always fit into a single iteration.
With the third option, the big problem is that you aren't delivering business value at the end of the story, which is generally a bad practice.
There are other ways you could split this work though. You could initially develop a very cut-down, barebones version which would work across all clients, and then refine each of them in subsequent stories.