Prakash was confused.

He had spent time in coming up with a high level epic, that was to be taken up in the coming quarter.
He had explained the big picture to the team, using the whiteboard.
Since there were no questions, he assumed that the team had understood the big picture.
Epics, were, anyway supposed to be high level stories..

His Epic read as follows:

As an Analyst, I would like to make better recommendations for my clients, with at least a 10% improvement in returns, so that my fees and margins would also increase.

Rationale:

The fee for the analyst is based on the returns for the client and the better these recommendations are, greater will be the fees for the analyst, with an increasing rate slab, with higher returns.

There were no stories created in this epic, and Prakash expected the team to come up with stories to implement the above requirement.

The team had come back with a request to be more explicit and give them stories

How would you help Prakash get more clarity on what is needed by the team and how he can articulate the epics more effectively?

 

Suggested Solution:

The above does qualify to be an epic, but possibly more as a theme or even an initiative.

That is because there could be more epics under this.

If you have the bigger context captured in a diagram [easier], we can drill down further.

For example –

To get 10% improvement, we need the baselines.

Where are these going to come from?

Any dependencies with other systems for data or interpretation?

Can these be available as algorithms in real time or are they reports that the analysts would see and take decisions?

Is the history of past performance being captured / logged? That could also spawn a set of stories [or epics], for analysis

How is the feedback on performance shared with the analysts?

In real time?

Would there be more social features to share who has been doing good or are faring better – more like leaderboards..

Etc etc etc

Now, if any of these or other such aspects are all laid out on the workflow model – or DILO – we can have a clearer picture of which functionality is needed when and also how it would be used which can help the design team to choose how it would be shown and the design of the interaction.

Each of these aspects could lead to one aspect of the information architecture needed.

I see the need for Prakash in this case as follows:

  • Get the full [or at least a larger] picture
  • Identify components [features, modules – whatever he is comfortable with for now]
  • Identify interactions between components
  • Identify workflows
  • Detail out what needs to be done by each of the components
  • Lay them out in a story map
  • Determine what is must have for release 1
  • Work with the devs to create these plans