I need suggestions for solving the following optimization problem
I have N jobs, J1,J2,J3,J4... JN.
I have n persons to finish the above jobs. P1,P2,P3....Pn
I have some constraints like only specific persons can do certain jobs. For example P1 can do only J1,J4,J5, P2 can do only J2,J7,J14,J8,J9 etc
The persons are available for certain periods of time of day. Like P1 available for 9am to 11am and then 12 noon to 3pm and then 3:30pm to 6pm. Like that applicable for other persons have their available times.
The traveling time also need to be considered based on the job locations and current location of persons.
So ultimately the genetic algorithm need to provide an optimum solution in form of a schedule. The following diagram shows below
On first sight, it looks like Project Job Scheduling, which is a form of Job Shop Scheduling. The Mista2013 competition featured that problem and several papers describe several implementations for that.
But a closer look reveals that this is more of a Vehicle Routing Problem with Time Windows (VRPTW), for which there also many papers available too.
Related
First time asking question, apologies if incorrect.
What would be the best way to approach this problem (Similar to travelling salesman, but I'm not sure if it runs into the same issues).
You have a list of "tasks" at certain locations (Cities) and a group of "people" that can complete those tasks (Salesmen). This is structured over a day, where some tasks may need to be completed before a specific time and may require specific "tools" (Set number available). The difference is that the length between each location is the same in all circumstances, but they all have to return to the start. Therefore, rather than trying to minimise the distance travelled, instead you want to maximise the time each salesmen spends moving and stays at the initial staring node. This also gives you pre-defined requirements.
The program doesn't need to find an optimal solution, just an acceptable one (Greater than a certain value.) Would you just bash out each case? If so, what would be the best language to use for bashing out the solutions?
Thanks
EDIT - Just to confirm, the pre-requisite where all the cities are the same distance from each other is just for simplification of the problem, not reflective of real life.
I'm a college student who volunteers as a program manager for a local community service organization. One big part of my job involves matching volunteer schedules (submitted to me via text and email) with tutee schedules (submitted by teachers via a google form). For the past two years, I've been matching the requested time slots with volunteer availabilities manually with excel sheets and color coding. This has been easy so far because I've received a relatively small number of tutor requests and volunteer sign ups.
Over the past two months, I've worked hard to grow the tutoring program at the school I manage. This semester, I received 18 request forms for over 25 students. Matching volunteer schedules manually for this many people will take hours, if not days, for me to complete. Given my work load, I figured there'd have to be a better way to approach this problem.
I am curious if any of you all with constrained programming experience could help me (1) solve my scheduling problem or (2) recommend software that can help. Below I will outline the scheduling process in more detail and list the constraints that must be taken into consideration when scheduling shifts.
THE SCHEDULING PROCESS
I ask my volunteers to send me their Monday - Thursday availability in a format like so:
M: 9:30 - 12:00
T: 2:00 - 4:30
W: 12:00 - 1:30
Th: 10:00 - 11:30
The school is a 15-20 minute drive away, so I rely on 'drivers' to carpool other volunteers to their 1-hour shift. If the volunteer has a car and is willing to carpool, then I try and match at least 2 other volunteers with the same availability with that driver (given that the car has enough room and a tutor has been requested by a teacher for that time slot).
I then pray that a teacher has requested a tutor for that carpool's time-slot. If not, then the carpool is no good and I have to manually come up with another solution.
THE CONSTRAINTS AND VARIABLES
Obviously, there are several constraints and variables that come into play when making the schedule. I will list as many as I can below:
Is the tutor a 'driver'?
If the tutor is a 'driver,' how many seats does he have?
Does the driver's availability match up with any of the requested time slots?
Are there other, non-driving tutors that have the same availability as the driver? (i.e. is there anyone that can carpool with the driver)
Do all volunteers in the carpool have a student they could tutor?
Did the teacher request individual or group tutoring (i.e. one or more tutor for one or multiple students)?
If yes, how many tutors did the teacher request?
REMEMBER, one volunteer can tutor more than one student
That is a small list of the constraints and variables I can come up with off the top of my head.
So can anyone offer a solution to this scheduling problem? Would someone who has no knowledge about constraint programming be able to use OptaPlanner to solve this problem?
Thank you for giving this a read and offering your advice.
You can use OptaPlanner for solving this problem, but it feels like Minizinc could be a better option. My point is that in case of Minizinc you describe required properties of a solution, instead of implementing workflows and algorithms to manage variables, constraints, parsers for input data etc, in case of OptaPlanner.
If one is not experienced with constraint satisfaction, it could be much simpler - just describe allowed/disallowed configurations in a text configuration file and run a solver. You can even provide a simple GUI for generating input data.
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 understand that on the first part of your sprint planning, you would size the stories for example using story points and poker cards and then you estimate how many stories you can tackle on the next sprint. So let´s say you agree on working on 3 stories with a total combined of 18 story points.
Then you go ahead with the second part of the sprint planning and you start breaking those stories down into tasks. These tasks are now estimated using actual hours.
I have two questions:
1) How do you estimate the tasks in hours? do you use again poker estimating but with number of hours this time? how does the team agree on the number of hours for each task.
2) Once you estimate all tasks for the 3 stories you agreed for the sprint, you find out that the number of total hours combined for all tasks of all 3 stories is 90 hours for example. If your actual team capacity in hours is 75, how do you adjust your initial commitment of delivering 3 stories now that you realize that you don´t actually have the time to do it? Do you go back to your Product Owner (if he´s not there anymore) and tell them that you will be delivering 2 stories instead or how do you go about this?
Thanks a lot in advance for your help!
The tasks are not really estimated in hours but ideal hours. It's really hard to predict how many ideal hours will be available in a week, and it's generally not a good idea at all to infer the capacity on a sprint based on hour estimates. See for example this Scrum Alliance blog article
Story points and task hour comparison can be thought of as the comparison of the weight and height of an elephant. In general, a taller elephant may be heavier than a shorter one, but this is not always the case. There is no biological proof of a weight-versus-height formula, despite the common perception that more height means more weight. The same explanation applies to story points versus task hours: In general, a more complex user story (higher points) should take more hours to complete, but there are always exceptions.
Normally, tasks are tackled by a single team member (or a pair), and thus they are estimated by them, and not by the whole team.
Furthermore, tasks are re-estimated daily: the number we look for is the number of ideal hours left to complete the task and not the total amount. So, it is a number that can go up or down, or remain constant.
Also, tasks can be added or removed during the sprint. It's actually pretty common to discover that initial plans change. It doesn't matter, as long as the total number of hours planned represents the best current estimate of what's left to do -- it's needed for burndown charts.
In conclusion, don't mind the hours. Use them to monitor progress during the sprint but not to determine capacity. This is what points are for and the two parameters are not interchangeable as it would seem.
In my experience, breaking into and estimating tasks is very useful and often underated. The idea is that the team become more and more accurate as time goes on through their sprints and they inspect and adapt. I have observed teams getting to the point where they end up completing everything in the sprint except for unforseen blockers (eg. Server down time). The idea is that the team calculate their capacity in (hours) and then calculate the amount of tasks they need to complete ( in hours). They can use this as a guide to make a commitment. There is a more detailed explanation here: http://www.pashunconsulting.co.uk/team_commitment_blog.html
You can also use story points to make a commitment but the general principle is that Story points are better for long term estimation (ie. for estimating when the project will deliver). Agile Estimating and Planning is a good book for this kind of stuff, as is the Scrum Mega Pack.
I guess an issue come from the assumption that you are able to deliver 18 points within a sprint. What looks not right when you do an estimation in hours later. So, commit to fewer number of story points initially and after several sprints you would be able to know your actual velocity in story points per sprint.
While breaking stories into tasks is helpful, it is not very useful to estimate those tasks.
The reason is that you will spend a lot of time doing these micro estimates and they will generally be inaccurate.
Besides, adding concrete hourly estimates forces work to fit in those estimates.
If you underestimated you might procrastinate, if you overestimated you might skip on reviews, unit tests or other quality practices just to fit the timeline.
So in general I like to stay with one estimate level -> the one that gives the velocity.
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've been recently implementing Scrum and one of the things we often wonder is the granularity of tasks within stories.
A few people inside our company state that ideally those tasks should be very finely grained, that is, every little part that contributes to delivering a story should represent a task. They argument that this enables tracking on how we are performing in the current sprint.
That leads to a high number of tasks detailing many technical aspects and small actions that need to be done such as create a DAO for component X to persist in database.
I've also been reading Ken Schwaber and Mike Beedle's book, Agile Software Development with Scrum, and I've taken the understanding that tasks should really have this kind of granularity; in one of the chapters, they state that tasks should take between 4 to 16 hours to complete.
What I've noticed though, is that with such small tasks we often tend do overspecify things and when our solution differs from what we've previously established in our planning meetings we need to create many new tasks or replace the old ones. Team members also refrain from having to track each and every
thing they are doing inside the sprint and creating new tasks since that means we'll have to increment our total tasks in our burndown chart but not necessarily adding a task that aggregates value.
So, ideally, how granular should tasks be inside each story?
Schwaber and Beedle say "roughly four to sixteen hours."
The upper bound is useful. It forces the team to plan, and helps provide daily visibility of progress.
The lower bound is a useful target for most tasks, to avoid the fragility and costs of overspecification. However, occasionally the team may find shorter tasks useful in planning, and is free to include those. There should be no mandated lower bound.
For example, one of our current stories includes a task to send something to another team -- a task that will take 0 hours, but one we want to remember to finish.
The number of tasks in your burndown chart is irrelevant. It's the remaining time that matters. The team should feel free to change the tasks during the sprint, as Schwaber and Beedle note.
On my last assignment we had between 4 and 32 hours per task. We discovered that when we estimated tasks to more than ~32 hours it was because we did not understand what and how to do the task during estimation.
The effect was that the actual implementation time of those tasks varied much more than smaller task. We often also got "stuck" on those tasks or picked the wrong path or had misunderstood the requirements.
Later we learned that when estimated tasks to be that long it was a signal to try to break it down more. If that was not possible we rejected the task and sent it back for further investigation.
Edit
It also gives a nice feeling to complete tasks at least a couple of times a week.
It also gives rather fast feedback when something does not go as planned. If someone did not complete an 8h task in two days we discussed if the person was stuck on some part, if somebody else had some ideas how to progress or if the estimate was simply wrong from the beginning.
Tasks should probably take one-half day to a day, maybe as much as two days sometimes.
Think about it this way: on a more macro level, short iterations promote agility by creating small amounts of value quickly and allowing plans to change as business needs change. On a more micro level, the same is true for tasks. Just like you don't want to spend 3 months on a single iteration, you don't want to spend a week on a single task.
Daily standup meetings can give you a clue that your task size is too big. If team members frequently answer "What did you do yesterday?" and "What will you do today?" with the same answer that they gave the day before, your tasks are probably not small enough.
An example of that would be if a team member regularly answers: "I worked on BigComplexFeatureObject today and will work on it tomorrow" for more than one day in a row, that's a clue that your tasks may be too big. Hopefully, the majority of days a team member will report having completed one task and be about to start another.
Short tasks, 4-16 hours as others have said, also give the PO and team good feedback about project progress. And they prevent team members from going down "rabbit trails" and spending a lot of effort on work that might not be needed if business desires change.
A nice thing about having many smaller tasks is that it potentially gives the PO room to prioritize tasks better and optimize delivered value. You'd be surprised how many "important" parts of big tasks can be postponed or eliminated if they are their own small task.
Generally a good yardstick is that a task is something you do on a given day. This is ideal, which means it's rare. But it does fit nicely into that 4-16 hour estimate (some take half a day, some take two days, etc.) that you gave. Granted, I don't think I've ever spent an entire uninterrupted day on a single task. At the very least, you have to break for the scrum meeting. (At a previous job a day of coding was considered 6 hours to account for overhead.)
I can understand the temptation of management to want to plan every single granular detail. That way they can micro-manage every aspect of it. But in practice that just doesn't work. They may also think that they can then use the task descriptions to somehow generate detailed documentation about the software, essentially skipping that as an actual task itself. Again, doesn't work in reality.
Agile development does call for small work items, but taking it too far defeats the purpose entirely. It ends up becoming a problem of too much up-front planning and having to put in a ton of extra re-planning any time anything changes. At that point it's no longer agile, it's just a series of smaller waterfalls.
I don't think that there is a universal answer to this question that fits every situation. I think that you should try what your collegues are proposing, and after the first sprint or two you evaluate and see if the process needs tweaking to accomodate everyones needs and wishes.
That 4 hour figure sounds like a good minimum to me. I like to think in terms of visible results. We don't have a task per line of code, or a label on a screen, or per refactored utility method surely? But when we get to something that someone else can use, like a public class used by someone else, or a set of fields on a screen that allow some useful action then this sounds like a trackable task to me.
For me the key question is "Do we know we've finished it?" with individual helper functions there's a pretty good chance of refactoring and change, but when I say to my colleage "Here, use this" it either works or it doesn't. The task's completeness can be evaluated.
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've been learning Scrum and trying a tool called Acunote for use with it. My question is about two fields I have there, for each task. They're "estimate" and "remaining". What unit should I use for those? Do I use Story Points? What about the remaining? For example I have a task that will take 10 units, let's say. I fill the remaining at the end of day with how many "units" I believe it will take me to complete?
Thanks!
I have a few suggestions for you:
If you are new to scrum; use a whiteboard and don't get bogged down in a particular tool's semantics; it will hamper your learning and adoption.
Break your stories small enough so that you don't have to create and estimate Tasks.
Don't do anything with hours, it is a waste of time to estimate at that level.
Burn down story points.
It is all too easy and common for teams to "think" they are on track because Tasks are being completed and burned down. Then they get to the end of the sprint and find that 5 stories are all 90% done and nothing is completed. If you burn down stories you are actually tracking deliverable business value and not just an arbitrary amount of developer-junk.
As always, my first advice would be to not use a tool when adopting/learning Scrum (I start to be tired to repeat the same thing over and over :). Instead, start with the simplest thing that could possibly work (a spreadsheet for the Product Backlog, a white-board and post-it notes for the Sprint Backlog). The rationale behind this is that you want to learn and master Scrum, not a tool. So don't let a tool tell you how to do Scrum and drive the process.
Then, regarding the question, there are 2 schools of thought: 1. what Scrum says in theory, 2. what some people do in practice.
In theory, Scrum has two levels of estimation: one for work (Tasks) to be completed within the current Sprint and one for more distant Product Backlog Items (PBIs). At the Product Backlog level, items (the "what" is being built) should be estimated in Story/T-Shirt/Unit-less points which have a low degree of precision. This approach avoids "analysis paralysis" pitfalls and accurately reflects the general uncertainty surrounding the work in question. At the Sprint Backlog level, items are beaked down into tasks (the "how" a PBI will be achieved) that are estimated in hours. A separate estimation scheme is appropriate because Tasks describe granular work (usually on the order of a few hours, never more than 16h). In fact, Scrum recommends using "ideal engineering hours" for Task-level estimates.
In practice, some people don't estimate in hours because burning down hours doesn't show "real" progress, which isn't false, and they prefer to burn down Story Points (which really means an item is done or not, it's more binary).
While I understand the "spirit" of the later approach, I don't apply it and stick with the theory. Actually, for the reasons previously mentioned, estimating in hours does make sense to me and I actually find that it gives better "control" of the Scrum empirical process during a Sprint (at the end of each day, you should update the estimated remaining work regardless of the actual time spent and this is easier with hours).
Moreover, I don't like the drawback of having only small stories (which can be seen as waste too) but like when a team identifies clearly what has to be done within a Sprint (this is good for transparency and helps the Product Owner to understand the real amount of work too, especially "quality oriented" tasks).
Finally, I think that you can avoid the pitfalls mentioned by DancesWithBamboo with hours too. Just stay vigilant and:
Always focus on the most important PBIs (and related tasks) first.
Pay a special attention to non-finished tasks, they should keep moving on the white board (if you are using columns to represent steps like for example "todo", "in progress", "to be verified", "done"); a non moving task is a smell.
Don't start a new item before the previous is done.
So, in my opinion, it is possible to use hours and to avoid the "nothing done" at the end of the Sprint syndrome. Just use your brain (Scrum and/or any tool won't replace it, luckily for us).
Having that said, and if you don't throw your tool away, the questions to answer are: what do you want to show on the burndown (points or hours depending on if you breakdown the work into tasks or not, I gave you my point of view) and what field does Acunote use to draw the burndown (i.e. where should I update the estimation of the remaining work). If you choose points and don't use tasks, it wouldn't make sense to update remaining work unless it's totally done IMO (a PBI is done, or not).
IMHO you shouldn't use remaining for the SCRUM points, because the points should be really subjective and you probably can't say how far you have gone.
I would recommend that you break the task into smaller ones (these ones would be the steps you need to implement the features) and then estimate them into hours. This way you can easily track the progress of the feature
Use hours for both the initial estimate and the remaining time. Tasks are usually estimated in hours.
You can use Scrum point - or any other unit - to estimate the backlog items.
I would not bother with remaining. A story or a task is boolean (either done or not done).
In our team we started to accept only tasks that are expected to have less than a day. That way no team member should be working on the same task on two consecutive daily scrums. The third day for sure rings alarm bells!
Also breaking up in task is easy and fast, because it doesn't take much estimating. Is it less than a day: OK, otherwise break it down.