Love the order ahead use-case: https://developer.squareup.com/docs/orders-api/order-ahead-usecase
Trying to figure out though. It says: "The customer kicks off the process by ordering one small coffee and one chocolate chip cookie using your order-ahead app. The customer chooses to pay using the app and pick their order up at CoffeeCool’s location."
Can the customer therefore "choose" to pay at pick-up? I'd still want the created order to be sent to the POS, so that the kitchen can start preparing it and the customer is not waiting.
Essentially this would be like replicating the "Save" rather than "Charge" option if this order were being manually made at the Square POS.
Currently only orders that have a charge associated to it will appear in the Square app and unfortunately the option to pay at time of pickup isn't currently available.
Yes You Can. You can set it up from the dashboard ( your computer) not directly from the POS. The issue is that it will prompt you to give a name to the order
I'm trying to simulate a movie theater. Movies start and end at specified times, no matter when a customer arrives and sits down. I want to be able to start and end the delay by time based units, kicking everyone out at the same time (once the movie is over)
I've tried googling - because I am a student and this was way too ambitious to try but I really wanted to. I'm literally hoping for any kind of insight
Select output, 4 different services (not ped), ped go to, then all same sink
I want it to work and it doesn't
Try thinking of your movie as an agent. Each movie can have its own event, which you could set to go off at a specific calendar date/time. In the action of the event, you could send a message to all your customers that they can now leave the theater...or, if your customers are in a queue with a hold block for that particular movie, you can just unblock the hold.
With movies as agents, you could have a start/end time and then create your population of movies from a database linked to Excel. That is, you would be able to set up your movie schedule outside of AnyLogic, which would probably be easier for whoever your stakeholders are.
Your question is probably too broad to answer fully in stack overflow. There are a million different ways to model a movie theater, and approach would depend on what you are trying to answer, animation requirements, your comfort level with programming, user interface requirements, etc.
The team I manage has been using TFS for years, but we've used a 3rd party system for tracking bugs and features. I'm looking to upgrade our team into TFS 2013 and I've done tons of reading and research into how TFS manages work items, backlogs, iterations, tasks etc. And although I understand the principles of what 'can' be done, I'm having a hard time visualizing 'how' our team would work with these work items as tasks.
If anyone knows of any best practice guides for actual sample based usage, or can answer any of these questions that'd be great
1) Product backlog - Under the 'configure schedule and iterations' what is the concept for setting the current 'backlog iteration'? Our team uses short 2 week iterations with a build number, but setting the build iteration as the current backlog makes all new PBI's scoped to only that iteration. Any items not complete in that iteration would disappear once I set the current build to the next iteration number. On the other hand, if I set it to the parent root node, I could see the PBI list getting rather large over time. What is the best method for managing PBI's that are unassigned and working in a simple Parent->build1/build2 etc structure?
2) Features - So I create a feature, perhaps it spans many work items and several tasks. They get completed over time, but I've noticed there's no 'auto' complete or status updates on parent items. So who/when is a Feature item supposed to get marked complete? If the product owner is supposed to use the features list to get an overview of work, they have no idea if all the dependent items have been complete and when to mark the feature Done.
3) Work Items - Managing these, and in particular their 'state' or status seems like a royal pain. On the task board you can't change their state, only their tasks with drag-drop, which is nice. But you complete all the tasks, and the parent work item stays in status 'New'. Do you really have to micro-manage every work item, open it up, and set the state to Done?
4) QA/testing - For every work item, each team member is responsible for testing each item, so every item is tested by multiple people, and logging any issues found. What's the best way to use work items or tasks for this?
5) Build Complete - Once every work item in the iteration is marked Done then I assume they are removed from the product backlog correct? The exception to this seems to be the features they were tied to, the feature item itself remains open. How do stakeholders view a list of features that were completed in the current build?
I can't answer everything (indeed, there is no one "right" answer), but here's how my team uses TFS - it might give you some ideas:
We use Area Path to represent a Project or Epic that work belongs under. When a work item is created it is assigned to a project using the Area Path, and it never changes.
Then to represent "when" work is done we use a hierarchical iteration path under 3 headings (for a project called "Project"): Project\Completed, Project\Current, Project\Future.
Stories in the product backlog are initially assigned to Future (We go a bit further in fact and use New stories to represent "proposed" work, and Active ones to represent the "approved" backlog - this allows us to plan tentative projects/contracts that convert into real work when they get the green light). At this stage we do Planning Poker to get Story Points and then the Project Managers assign stack ranks to the stories to help to decide what to move from Proposed to Product backlog, and then eventually what we should think about for the next iteration.
When we start an iteration we create a new iteration (call it 001) under Future, i.e. Project\Future\001. Then Stories are chosen from the Product Backlog for implementation - they get assigned to this iteration. When the iteration is ready to start, we use a "conveyor belt" approach which moves all the iterations along one "place" in the hierarchy: In the Iteration Path configuration UI, just drag the 001 iteration from Future to Current. This re-paths everything in that path automatically so that all the active work is instantly under Project\Current.
As we complete the iteration, we would have Current\001 and we'd then add Future\002. Then we move 001 and 002 along the conveyor (to Project\Completed\001 and Project\Current\002 respectively). This way the work gets assigned to one iteration and stays there, but the iteration as a whole moves from future ...to current ...to completed. This allows us to build queries like "all current work" (all work under "Project\Current") that we don't need to rewrite for every iteration, and this saves a massive amount of time and eliminates a lot of mistakes trying to re-assign iteration paths constantly - in most cases the iteration is only changed once (from future to an actual iteration).
When a story moves into the current iteration, we choose an implementing team (e.g. an owner to accept delivery, and a developer and a tester to implement the work) and those people add tasks for any work that needs to be done to deliver the story. Any bugs/issues that crop up for that story during the iteration are also parented to the Story or Tasks.
We found the TFS tools pretty poor (clumsy, slow, micro-managing), so we now use a home-built dashboard that shows us a list of stories, so in our scrum we can step through the stories and see the tasks/bugs/issues for each, who is working on them, and how much work they reported on the task since the last scrum. This gives us a really clear basis to discuss the story.
We close tasks/bugs/issues as we complete them, but the story stays open till the end of the iteration (so that any new bugs found can be attached and dealt with). We then use a custom tool to "Resolve" the story, which closes all the child work items, and then checks if the parent Feature or Epic is now completed and can also be marked "Resolved". This can also be done in stock TFS just using a manual process, but it is rather laborious, and the code to automate it is only an hour or two's work. I really don't understand why TFS makes you essentially update all the database tables by hand when it's so easy to automate. (In a similar way, the TFS kanban is unnecessarily time consuming to manage because items only appear on it if they are perfectly formed - get any of the estimate, remaining, completed, area, iteration, assigned-to, parent link, etc wrong and it vanishes! So I've written e.g. a simple 'create task' tool that asks for the estimate, assignee and title, and fill in the rest - this took me a couple of hours to implement and has eradicated all the time consuming errors and hassle of using TFS 'raw')
When processing tasks, TFS provides 'Activity' states (planning, development, testing, documentation etc) - which implies that each single task will be passed linearly through a chain of different people to be implemented... but we feel this is a poor approach, because we want to encourage the team working on a story to work in parallel and work together, not "throw their bit over the fence to the next guy". So instead each person on the team creates one or more tasks under the story that represent the parcels of work (programming, testing, documenting) they must personally do to deliver the story, and each task only ever has one owner. (This works well in our scrum dashboard because it shows the story and its list of child tasks/bugs/issues, so the entire context of the story's work can be seen easily at a glance). The separate tasks allow the programmer and tester to work together in a tight, iterative, co-operative agile loop, often with progressive roll-out of parts of the feature for testing, rather than the programmer finishing all his work before passing the complete article over to the tester in a waterfall-y way. At the end of the iteration, the story-team demos their story to the wider development team, and they are all equally responsible for ensuring that everything needed is delivered. After the demo, the Product Owner/Champion then accepts the work as done (or rejects it). This vastly reduces the amount of work that gets dropped "between the cracks" where people think somebody else will do it, helping us to get to a solid delivery at the end. We've found communication within the team and story delivery significantly improved since we moved to this approach.
I should mention that to get good estimates and burn-downs we try to keep each task less than 5 days work, and to avoid micro-management we try to avoid splitting down tasks into anything under about 2 days (though obviously some tasks are necessarily shorter).
As I've mentioned, we log bugs/issues as children of the task or story they affect (and can also add Related links if they impact more than one story). At the end of the iteration as well as demoing the new features to the rest of the team, the release build is regression-tested as a whole. Any bugs found are fixed in a release branch and within (hopefully) a day or two we have a stable customer release. We aim to have a product of customer-releasable quality from every iteration, and to keep the number of outstanding bugs per developer below 5 (usually 1-3). Before introducing this system, we had an ongoing average of 20 bugs per developer, an unpleasant technical debt. (Note: we reserve some time in every iteration for fixing these bugs, but when bugs are too gnarly to fix then-and-there, we usually convert them into new stories so that they can be estimated and scheduled for a future iteration just like other work, so the bug-list and technical debt is never allowed to build up, and where possible bug fixing is not allowed to derail our iteration plan.
We don't treat work in progress (items in an iteration) as Product Backlog - the product backlog is work that we plan to do in the future, and when it moves into an iteration it becomes actively worked on and no longer in the "to do" list (it's the Iteration backlog, not the Product backlog). When all of the work (task/bug) is complete, then the parent story can be Resolved ('we think it is "done"') and then Closed ('the Product Owner accepts it as "done"') and so a simple query (work under Project\Current that is Closed) will tell you what you have delivered this iteration.
Lastly when we close out the iteration, the whole iteration moves into Project\Completed, so then you can easily query all of the work which has ever been completed (under Project\Completed), and still grouped within their individual iterations. So at any time if you want to know what "Build 107" added, you can just do a query for all Closed stories under iteration path Project\Completed\107. We mark incomplete/abandoned work as Removed, so for us Closed means "Done". If work is not completed in one iteration and is continued in the next, then we simply move the story to the next iteration, and so the completed work then shows up in any queries for "Build 108" instead - so this perfectly tracks the achieved deliveries for an iteration.
To keep things consistent, only a few team members can change different types of item. So our "planning items" (Epics, Features, Stories) are only changed by the Project Manager or Product Owners. Tasks are all owned and thus created/changed/closed by the developer that is doing the work. PMs track progress of stories and devs track progress of tasks.
1) Product backlog - Under the 'configure schedule and iterations'
what is the concept for setting the current 'backlog iteration'? Our
team uses short 2 week iterations with a build number, but setting the
build iteration as the current backlog makes all new PBI's scoped to
only that iteration. Any items not complete in that iteration would
disappear once I set the current build to the next iteration number.
On the other hand, if I set it to the parent root node, I could see
the PBI list getting rather large over time. What is the best method
for managing PBI's that are unassigned and working in a simple
Parent->build1/build2 etc structure?
TFS has two different backlogs. The Product Backlog of your team and the Sprint backlog of your team. In the iteration configuration screen you define which iteration contains your teams product backlog (by setting the Backlog iteration) and which iterations below that will represent your sprints .
If you have a large list of PBI's you could put these either in an iteration above the current backlog iteration, which will effectively hide them from the backlog pages. Or you can place them in a separate iteration that is a sibbling of your Backlog iteration.
2) Features - So I create a feature, perhaps it spans many work items
and several tasks. They get completed over time, but I've noticed
there's no 'auto' complete or status updates on parent items. So
who/when is a Feature item supposed to get marked complete? If the
product owner is supposed to use the features list to get an overview
of work, they have no idea if all the dependent items have been
complete and when to mark the feature Done.
There is no auto-complete or auto-close. Normally the Product Owner (scrum role) will keep an eye out on what he has requested and knows just about when a feature is about to be completed.
You can also view the hierarchy of Product backlog items to features in the Product Backlog view by selecting the Features to Backlog Items view. This will also list the states of the underlying stories:
3) Work Items - Managing these, and in particular their 'state' or
status seems like a royal pain. On the task board you can't change
their state, only their tasks with drag-drop, which is nice. But you
complete all the tasks, and the parent work item stays in status
'New'. Do you really have to micro-manage every work item, open it up,
and set the state to Done?
Normally the product owner/project manager will approve stories for pickup and move them from new to approved. Then during the Sprint planning meeting (or at the start of a sprint), the team selects which items they will work on and will move these from Approved to Committed.
Then at the end of the sprint (or when all tasks under a story are done), the development team shows the product owner the finished work and then moves the story to done as well.
4) QA/testing - For every work item, each team member is responsible
for testing each item, so every item is tested by multiple people, and
logging any issues found. What's the best way to use work items or
tasks for this?
Depends on the maturity of the team. And depends on your adoption of Test manager (Test Case work item). If your team is pretty mature and is using Test manager to link Test Cases to your Stories, then you can view the status of your tests in Web Access. If the team consistently works in a ATDD way of working, they'll do the work needed to make a test succeed before moving on to the next piece of work. In such a workflow it's not really needed to create "design-build-test" work items. The work item would probably be akin to "Make test X pass" and would include all the work to create the test, build the code and make the test pass.
5) Build Complete - Once every work item in the iteration is marked
Done then I assume they are removed from the product backlog correct?
The exception to this seems to be the features they were tied to, the
feature item itself remains open. How do stakeholders view a list of
features that were completed in the current build?
Again, use the Feature to Product Backlog Item view to see which features have had all their work finished. The stakeholders mentally verify that this was indeed all they wanted and that they have no additional requests, work, feedback that is needed to truly complete the feature. If this is the case they will close the feature by moving it to done.
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 attempting to write my requirements out as User Stories. Moving from a waterfall world, I am much more familiar with Use Cases.
One of the things I like about Use Cases is each interaction with the system is well-defined, as well as all the alternate and exception flows of action.
UC-01
Success Scenario:
The user navigates to the customer
The user clicks the Add Contract button
The user fills in the Contract Name, Contract #, Start Date and End Date fields
The system asks for confirmation
The user fills clicks the save button, and the contract is saved
Exceptions
5a. The user aborts, and the contract is not saved
Alternate flow
1a. The user uses the filter to select the customer
Where would the exception and alternate flows be captured in an Agile approach?
They wouldn't be captured as such.
You are approaching user stories from the wrong angle. Coming from waterfall this is quite a common misunderstanding.
Your story in this example should be something like:
As a user I want to add a contract to a customer so that [insert value here]
From the example you can note two things:
I can't finish it because I have no idea of what the value of this story is to the customer. This is quite important because it drives any negotiation over the story. For example, one doesn't want to spend a lot of time on stories which have a very marginal value.
There isn't much detail. This is on purpose, because the story tries to capture the problem or the opportunity, not the solution. As a user, there are many theoretical ways in which I can achieve my aim of adding a contract to a customer.
The focus of stories is letting the users achieve their goals.
Normally you can write details about how you currently speculate that the story will be implemented on the "back of the card" or in a notes field in your ALM tool, but the point I am trying to make is that stories are negotiable in how they are implemented.
Your developers are expected to interact with your customer representative during the iteration to discuss/prototype/try out the various different possible solutions so that the aim of the story is achieved efficiently and effectively.
A very simple and yet quite exemplary and typical example: what if you forget an edge case, alternate flow or exception? With stories, that's no problem: the developer discovers it, has a chat with the product representative, and they make up a plan to handle it.
You can do this because it's clear that handling these cases is part of the user story. Not so with the requirement, which is prescriptive on what the solution should be, instead of what it should achieve.
> Where would the exception and alternate flows be captured in an Agile approach?
A Use Case is a form of feature documentation.
This documentation can be created
before implementation (as specificatoin in waterfall)
during or after implementation or not at all (agil)
In Scrum you would just have a feature-request "Add Customer" in the Backlog without the scenarios.
Many agile practices do not dictate that you have to write your requirements out as user stories with acceptance criteria. All that is needed is a list of requirements (aka Product Backlog) that is ordered. When giving these requirements to the team in a sprint planning session they should be the minimal amount of information that is still clear enough for the team to understand and build. There is a fine line between doing too little grooming and over analysing the requirement; this takes time to get right.
Having said that, user stories are commonly used as they make sense to multiple parties involved in the process where other forms of requirements are limited to a specific audience; i.e. you have to teach people how to read and understand use cases but do not have to do that for user stories. Obviously writing it is a different problem.
I like #Sklivvz and #k3b answers.
Regarding your example.
First: As Sklivvz wrote, the User Story defines the problem and the goal. I differ in the opinion regarding side tracks and exceptions. Those are, in my eyes, small stories to. With there own priority. I.e. the ability to cancel the process could be of higher prio than some validation problem story.
My Answer in short: Write a story for the main goal, side goals, exceptions and alternate flows.
positive side effect: The product owner (you?) has the chance to prioritize those stories.
agree with some of the above and would like to add the following (hope this is useful).
Use Cases are not specifically/only related to waterfall, they are merely a means to visual behaviours (use cases) of a system and the relationships between those behaviours and other system behaviours, and external entities to the system (actors).
There is no reason why a user story cannot be further described by use cases and use case scenarios.
Remember, just because you are practicing (I guess, but not restricted too) Agile that does not means you cannot design stuff. Just don't let the design have more value over the result i.e the product (although in complex . safety systems this should be the case).
When you capture stories initially, they should be very brief and focused on benefits.
When you've discussed solution with the team and ready to start implementation, you should document it with more details.
I like Given/When/Then format and I'd re-write this Use Case into this (real goal may be different, but still you'll get the main idea):
Title:
As a user I want to add contract to customers so that I can track contracts history
Given customers list
When user clicks to Customer
Then he sees Customer Details view
And Add Contract button
[mockup]
Given Customer Details view
When user clicks Add Contract button
Then he see a popup with fields:
Contract Name - field spec: [default value, max lenth, etc]
Contract # - [field spec]
Start Date - [field spec]
End Date - [field spec]
[form mockup]
Given user filled form correctly
When he click Save button
Then he sees confirmation dialog ["Do you really want to add this contract?"]
[NOTE: I think this confirmation is stupid and not required]
Given user see a confirmation dialog
When he clicks Yes
Then the contract is saved
And user sees success message "Contract is saved for customer XXX"
Given user see a confirmation dialog
When he clicks No
Then the contract is not saved
And confirmation dialog closes
NOTE: most likely this scenario is a separate user story
Given home page
When I click Add Contract link
Then I see Contract form
And "Select customer" drop down field
...
As you see, you can quite easily use Given/When/Then format to describe user stories. It is very important to make sure that true value of user story is captured. Otherwise it is very easy to make some decisions that will be really bad from the business point of view.
In my application, users have a list of items that they can put in any order they like. The database schema looks like this:
Items
+ Id : int
+ Name : string
+ Order : int
so when the user puts things in order, it sets the Order field accordingly, so that I can sort it later. Great.
Now, I want to make the sort ajax-y, such that the user can drag and drop items into order (and use up/down arrows), and it will just automagically save everything. (If you're familiar with Netflix, they do a similar thing.)
The issue I'm having is that in order to persist the user's changes as they make them, I will need to do an AJAX call every time they do something. If the user moves an item from position 10 to position 1, that implies that I have to update 10 records in that little ajax call. Meanwhile, the user may have queued up 3 more AJAX calls to update other records.
This seems inefficient and like it might be error prone (due to race conditions and so on, if the AJAX calls take a long time.) Should I be worrying about this? Is there a more efficient way to do this? If it makes a difference, I expect most users will have fewer than 5 items to sort.
Since Javascript can't synchronize code, I agree that it would be difficult to implement code that would be sure to avoid race conditions, although I did find this article on implementing a Mutex in Javascript.
However, personally I think that rather than choose an option that is likely to result in race conditions, I would go with one of the following options:
Create a save button above the items, that when clicked will save the order to the database.
Create a timer that will save the order every five seconds (or whatever), if something has changed. You would still want a save button for this, so the users could force a save.
I would lean towards the latter. Obviously in both cases you would want some visual cue to the users that they have unsaved changes (like changing the background color of the items, for instance). You would most likely want to implement something that makes sure the user wants to leave the page with unsaved changes if you go with either of those options (like in Gmail, when you have unsaved changes in an email that you are composing).