View Full Version : Epics and Stories in Agile

John Cutler
07-17-2017, 06:14 PM
Let's crowdsource a post. I'll curate. Tips for a developer writing Epics/Stories for initial validation of new arch?



07-17-2017, 06:21 PM
How formal:
I think level of formalism requires a consideration of these areas:

work dependencies
competency of the team
at stake

Work Dependencies
Increasing levels of formalism can help address depending work, a measure of connecting the entire development system from beginning to end. We need to know the implications of work done in this team on those depending areas of the project or business. Is this work is effectively a stand alone, or will this go to some other department such as manufacturing, or some other depending part of the company. The more interconnecting or articulating points there are in the project, the more we should consider a higher level of formalism.

Competency of the Team
Increasing formalism helps to account for varying degrees of competency. As team competency goes up levels of formalism may be able to be reduced. In this case, the competency area is beyond the immediate area that a person by dint of their work for the project would need to know, or what may be called well rounded. That is not just coding, but perhaps configuration management and product testing at some level are but a few examples. It is essentially the level of ability that allows the team member to think about the product development as a system and consequences (systems thinking) of their actions to some effective future point.

At Stake
A higher degree of formalism can help when the consequences of error are severe or when the regulatory bodies may want to look at the work that was done. Consider for example, automotive product manufacturers or suppliers when a defect of some severity is found in the field, there will be reviews and exploration into how the work was done, and whether or not the company acted with the appropriate level of diligence (was undue risks taken). Higher degrees of formalism can make it easier to show the work done and why it was done the way it was - it provides a greater measure of trace-ability.

07-17-2017, 08:28 PM
Some interesting ideas and input from @JasonGuyWolf on Twitter

How do I frame experiments?
I think when it comes to experiments we need to understand the objectives and some of the alternatives that may be the mechanisms by which we can achieve to those objectives, or conversely, learn as quickly as possible that this experimental approach will not allow us to reach our stated goals. To that end, and for the sake of timeliness in delivery, we should prioritize those ideas that pose the greatest promise or the biggest potential benefits. That is not to say ignore the riskiest exploration, but take the riskiest approach if the reward or upside for this exploration, if successful, may provide the most benefit or greatest discovery. Of course, this is easier said than done, but with some level of systems thinking, we can make some broad deductions by thinking.

Ultimately, the scope of the experiment should be clear, and metrics that would allow us to assess if this approach will reap the rewards we expected or desire, or not. We should terminate this specific experiment when we learn that this approach will not meet the objectives, and the measurements should provide that feedback to the team. It would be beneficial to review this result with the entire team, to spread the learning if perhaps only part of the team was performing this experiment. This information spread among the team members may result in more ideas and perhaps another experiment that may have a higher probability for success.

07-18-2017, 05:07 PM
Some interesting ideas and input from @JasonGuyWolf on Twitter

How do I build support from the team?

As @JasonGuyWolf says, to build a team certainly requires trust, but it takes more than that I think. We have come a long way from the days of Fredrick Taylor’s Scientific Management. It is hard to believe, but it was not until the 1920’s that the notion of social interaction as a mechanism for improving the business outcome or output, a glimpse of which came about as result of the Hawthorne Study. Now, in some places, it seems management has lost focus on the scientific aspects of management (measurements) and dwell solely on the humanistic, both are in fact required in my opinion for success. More on that later writings.

If it were as easy or the ingredients for success were so trite or commonly known, there would be a good deal more actual teams than collections of individuals working toward some objective. There are organic, and very specific to the talent available and situations presented along with the responses that make prediction or creating a specific brew and viola a team is born. The first as @JasonGuyWolf says is certainly trust, but I think we must create an atmosphere where exploration, independence and interdependence are acknowledged.

Independence, in that each person is a free-thinking individual with aspirations and things that motivate them, review the of Maslow (https://en.wikipedia.org/wiki/Maslow%27s_hierarchy_of_needs)hierarchy of needs and Herzberg (https://en.wikipedia.org/wiki/Frederick_Herzberg)satisfiers and dis-satisfiers. This variation in motivation and source of motivation must be understood. Finding those things that motivate each specific individual and aligning the work with what motivates increases the probability of a well-motivated individual and the team.

Interdependence is a significant part of team creation, as each person relates to the other. This, in my view, is a significant part of team development as it moves our group from solely individualistic to an interconnection between the team members beyond just the work, that is a personal connection.

Personal interconnection with the individuals of the group
Matching work and objectives to individual motivation
Trust – ability to speak freely with no fear of reprisals
Understanding of and abiding by the team defined norms
Humor and fun in the work

As an aside, we are developing an online training on learning organization, organization development, and project management class (https://valuetransform.com/training/course/index.php?categoryid=19)

07-20-2017, 09:13 PM
To really write something about this, we should have a common starting point for the concept of convergence. Like any “requirement” type language, left unarticulated, it could mean whatever the person reading it thinks it should mean. In this context, convergence is the point in the design where the multiple experiments and alternatives that we can take to achieve the projects objective are whittled down to the one, best answer. Now, that one best answer, can be an amalgam of some aspects or attributes of those individual design alternatives we explored along the way. The thing is, we do not want to converge on the single best answer prematurely, as we may end up selecting the less than best answer for this project. By the way, this concept is not uniquely agile and in fact is part of the stage gate or waterfall approach. Our team will explore design possibilities, architectures and other possible solution iterations, and will seriously review / critique these possible answers to the design challenge. This can be done with experiments as well as thought or mental experiments and critiques such as decision matrix (Pugh Matrix or QFD). A crude example of these decision matrix can be found at:

As we think about, model or build prototypes or facsimiles of the product we are learning. We are performing tests to understand the trade-off we are making with each design, perhaps considering the possibility of mashing concepts or design attributes together to build a new and better solution. Over time, one design solution will emerge.


07-22-2017, 08:54 PM

We have talked about convergence from the design direction, where a number possible design solutions are explored before selecting what is deemed to be the best. There are other examples of convergence in systems development, equally if not of greater importance.

Consider a product that really is a collection of subsystems. These subsystems are put together at some point in the design cycle, to deliver the functionality the customer desires. Some examples of this are cell phones, automobiles and many other complex or intricate designs. The individual development teams have their respective design targets or objectives, but objectives are also connected to other designed parts, meaning the product outcome from each design team must work as expected with the outcome from other design teams. The phone electronics must fit into the hardware case, each electronic control unit (ECU) on the car must work with the other via hardware or data communications, and must be able to be mounted on the vehicle in a specifically define location. There are specific mechanisms within product development that are used to control or help synchronize these iterations, converging each subsystem or component eventually on the end instantiation of the product. These mechanisms are:

configuration management (https://www.valuetransform.com/cdm/)
project management (https://www.valuetransform.com/project-management/)

Configuration management provides a traceable roadmap – forward and backwards, of the product contents or system instantiation, effectively coordinating the design among the participants in the development effort. This is also the mechanism by which changes and design adaptation that are required over the course of the development effort, are managed. In this regard, the system development direction is orchestrated by configuration management as well as the ability to see how the latest iteration of the product came to pass.

Project management helps coordinate the design via task identification and schedule development along with associated responsibilities. Knowing who is responsible for what tasks, and how the results of their individual work, interfaces or has other dependencies.

Communication is important for any design coordination, team discussion, problem solving and learning, all are required to effectively and efficiently develop the product. The downside, will be plenty of money and time spent on rework.