Closed DuncanvR closed 9 years ago
Hmm... looking at this feature, I'm starting to wonder whether we need the prospective meeting at all.
To illustrate, here's the sequence with a prospective meeting:
And without prospective meeting:
The way I look at it, the prospective meeting doesn't provide any benefit, and we can keep the design simpler by removing it altogether. What do you think?
You're right, the design would definitely be simpler without it; but in my head it's part of the process. Let me explain --- I modelled it after the way we currently set up meetings.
Usually we start by deciding where we're going, i.e. who will be the host. At that stage, we'd have a prospective meeting as we've talked about so far. Then, we start proposing dates; some are promising, others not, but in the end we find one that's good for most of us. Ultimately, it's the host that decides which date is picked (I guess I'd model that by making the host of a meeting approve a date picked by the system, as part of P2
(the only feature that hasn't been specified yet)).
Now, of course we don't have to keep that work-flow in place; but so far I have tried to --- I think the two-step process will keep us a bit more involved, and avoid a huge amount of cancelled meetings that the system thinks are nice, but turn out to somehow not be very suitable. Anyway, that's where the prospective meeting came from.
What do you think, does that make sense? Or can we achieve the same without it?
Aaaah, we had completely different understandings of the prospective meeting :) As you describe it, it actually does make sense. This also means the sequence I wrote down is in fact a little different:
I think the prospective meeting indeed has an added benefit, but this feature still remains redundant. The first two steps should be integrated, because (the way I see it) a host is a prerequisite for a prospective meeting. Do you agree?
To clarify, I think the "setting up"-part in itself does not provide a lot of value. It's the choosing of a new host and assigning it to the next meeting that's interesting.
So you mean the Automatically assign host
feature and this one can be merged? Then we'll have to rewrite that one, as it has When the system plans a prospective meeting
which refers to this bit.
Yep! Unless you disagree of course ;)
On second thought: nope. You were on the right track initially. The business value of the "setting up"-part is engaging the participants, so it does have a right to exist on its own.
The only thing I'm still not sure about is whether this feature should contain all the scenarios of when a meeting should be automatically set up. So not only after a successful meeting, but also the first time when the application start and no meetings have taken place yet, and also when a meeting has been cancelled.
Those other two scenarios you mentioned should indeed be specified as well. I'm not sure they should be kept separate though, as both steps will always occur at the same time. The system will set up a prospective meeting and directly assign a host. They're easier to describe separately though, so I let's leave it like this for now.
While adding scenario's for the very first meeting and after a meeting is cancelled, I realised a more generic scenario could capture them all. How about this?
Scenario: Plan prospective meeting
Given there is no future prospective or scheduled meeting
When a preconfigured interval has passed # e.g. every hour or every other day
Then the system plans a prospective meeting
LGTM :)
While we're add it, here's another one! This time for
P1
as described in #2.