Giving context

I am in Norfolk and the weather is foggy, and I am thinking about how best to do Release Planning.

More specifically, how to plan for a big two-year project where everyone is used to a waterfall approach.

So, here are some thoughts.

Our problem is like being lost at sea in a fog — we need to get our bearings.

One metaphor is that we need to triangulate. We are trying to give ourselves some context, a kind of map, and, in our situation, we need not only the skipper or captain to understand our bearings. We need everyone participating, e.g., everyone on the team doing the estimating, to have their bearings.

Now, also imagine that we are doing this at scale, meaning, for example, with about 28 people in four teams. We have already done a high-level overview of the 15 key high-level ‘features’. So, within and between features, how do we enable everyone on the group to get their bearings? What are some good practices?

First, let’s understand our goal better.

Coming up with ‘the plan’ is not that important, but getting our people ready to do the work is very important.

One thing is to give them confidence that they basically understand the stories. If they lack confidence, they get scared to estimate, they slow down too much, and, if the stories are too vague, they should ‘slow down’. But at the start, there is always some vagueness, so we must live with some of that. As I say, “If you wait for perfection, you might wait too long.”

One thing is that they need to understand the stories in multiple dimensions, and in all the key dimensions that affect Business Value and effort (story points).

One thing is that they ‘basically’ understand the story, but they don’t feel compelled to understand ‘everything’ about the story now. They feel OK to discover much of the detail later.

So, we want context at the high level, including very high level process flows, Business Value, large epic relationships, etc. We do NOT need context at the very low level. At the extreme, we would have to do the whole project to discover ‘all’ that detail.

But, we do also need some ‘middle level’ detail or context, and each project or effort has to argue about how low is this middle level.

Part of the problem is sharing the explicit and tacit knowledge about what the customers and the firm want throughout the whole team. (I won’t try to explain now why the whole team is so important.)

So, here are some suggestions about giving or sharing context:

1. Creating the stories as a whole team. Among other things, the whole team starts to own the stories.
2. Discussing the relative Business Value of each story as a team. Perhaps with Business Stakeholders.
3. Seeing all the stories on the wall, and discussing relationships or groupings of stories.
4. Good use of the ‘role’ in story writing. Gaining clarity about each role. Personalizing each role. (‘You saw Suzy; this is what she does.’)
5. Better use of the ‘so that’ clause in the story line.
6. Reviewing the stories against the INVEST criteria. Are all the stories ‘good enough’ by these criteria?
7. More artfully sliced stories can make it easier for everyone together to understand. This is a skill that the PO and the team get better at with time.
8. Middle level business process flows (middle compared to the big system). Maybe ‘high’ compared to other things.
9. Some high level acceptance criteria per story.  E.g., one to four acceptance criteria bullets. Not necessarily for every story, but maybe just for some of them.
10. Pictures of interrelationships between modules of the big system. “That info will be here, and we use it there.”
11. Pictures of interrelationships between ‘layers’ of the system or ‘features’ or what role ‘X’ wants.
12. Seeing how stories are grouped, or how they were broken down. ‘We had this big epic, and we broke it down into these smaller epics.’
13. Understanding “what is role x really trying to accomplish here” can be very useful.
14. Reviewing the relative Business Value of each story. Business Value is not just what customers want, but also what the firm needs (e.g., lower risk or more revenue).
15. Pictures, pictures, pictures. Drawings, drawings. Discuss them. Discuss them again. Use the white board.
16. ‘It is not what I know (as the PO or BA); it’s what the whole team knows that matters.’
17. Some sense of the relative complexity of the business rules in stories.
18. Some sense of the relative number of data attributes (or whatever phrase you prefer) in a story.
19. Some sense of where this story ends and these other related stories begin.
20. Using Planning Poker to determine how much more context is needed. If they have some context and then vote, and the votes are close or quickly become close, then probably no more context is needed.
21. Communication. Doing something, and then asking everyone, “How can we do this better given our situation?” This includes our work, our people and what information is already available. Often they will end up with something that we meant above, but they want to use different words to express it, which is of course fine.

Final note (for now): Different teams get ‘stuck’ at different points. This is normal and not a big problem.  Unless they can’t get themselves ‘unstuck.’

 

 

« « Agile & Religion – 1 || Leadership – 1 » »