- Be not an order-taker - either as Business Analyst or as Product Owner; taking that Wish-list of features to the Dev Team; your role is to Elicit Requirements and not writing them down.
- Engage the end-users in
a polite – and at times firm -conversation about where they are going,
where they expect to be, and if those goals and desires are reachable or
desirable. Custom software-development is very very expensive and
not for the faint of heart.
- We develop software to
Automate human tasks or to help human beings make decisions. Start
by asking the following questions:
- “What data elements are
needed to accomplish the goal of this system?”
- “What other data
elements could be added to delight and please the end-users?”
- “What data is needed to
reduce the cognitive load on the end-users when using this system”?
- “Where can I find the data for this system?”
- As Product Owner, you
own the product (even if you are working for IT) – meditate on a thousand
and one ways that you could expand and develop the system – all the time.
- BAs, Product Owners,
End-users are on a joint voyage of discovery – to create something new
that had not existed before – give it the respect that such an undertaking
deserves.
- In every meeting with
the end-users, present a very specific and narrow agenda. This
should be in the body of the Meeting Request. Supply a subject
matter as well for the meeting.
- Often, the customers
(end-users) are looking to us in IT to suggest technological solutions –
they do not know what is available. We should have the ability to
give them options and let them chose. For example, sometimes, a COTS
package – that is already licensed and deployed – may satisfy the
needs of the end-users in contradistinction to a ton of custom-code with
the latest IT buzzwords, languages, and frameworks..
- Like the space program –
always have at least two members of the Dev team present in the
requirements sessions, lest something be lost.
- After each and every
requirements session, meet with the Dev Team to go over what has been
discussed and revise the Product Road Map, the Software Specifications,
and the Software Architecture and BoM - if needed.
I think when meeting with the end-users, we are defining and fleshing out Business Use Cases (Business User Stories). I think it would be a good idea to meet separately with the Dev Team and flesh out the Technical User Stories.
The Product Owner, as end-users community’s proxy, owns the business requirements.
Since we do not have the role of a Requirements Engineer within development teams, it follows that the entire team owns the technical requirements.
Which means, in practice, that Dev Team members ought to actively participate – when warranted – in the discussions with the end-users as well as with the product owner.
The Dev Team owns three things: Software Architecture and
changes thereto, Software Specifications (Technical User Stories), and the BoM
– in my opinion.
