Sometimes
as a product owner you run into the problem of having to deliver a large piece
of a project. As mentioned on a previous
post you want to avoid going to technical and constraining a dev team to follow
what you’ve written when instead a story is the beginning of a conversation and
isn’t a commitment to exactly how something should be done. With a user story though you don’t want it to
be too big and so you need to break it down into manageable parts.
If
for example you need your team to create a new micro-service to process requests
for information you don’t want to write a story that doesn’t create any value
once completed. An example of this would
be writing a story that addresses the need to create a database for a user to send,
receive, and update information from.
Instead you’d write a story that starts perhaps with the first part of
the process, i.e. send data. With this
broken out into its own story it should be discussed with the dev team that
while we know that doesn’t encompass creating a database, receiving info, or
updating info they will inherently know or be explicitly told that a database
needs to be created in order to complete this story. It should be noted that the very first story
will also be front loaded with initial set up and configuration of other things
and so it may be larger than subsequent stories. That is ok though because we want a story to
be able to stand on its own in terms of value being delivered even if it is
only one portion of data being worked on, in this case sending information.
No comments:
Post a Comment